Date: Mon, 27 May 2024 16:03:49 +0100
strongly against a baseclass. The reason anyone would use anything but
std::elide is because they have their own, and changing that is
difficult.
Request a `bool std::is_elider_v<my-class>` specialization and then
have `template <typename X> concept elider =
std::is_elider_v<remove_cvref_t<X>>`.
On Mon, May 27, 2024 at 12:59 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Sat, May 25, 2024 at 6:04 PM Frederick Virchanza Gotham wrote:
> >
> > So what should be the canonical way of doing this in C++26, not just
> > for the standard library but also for programmers writing their own
> > classes?
>
>
> I'm thinking I'll go with the following strategy. The class
> "std::elide" will contain a typedef as follows:
>
> typedef std::true_type tag_elide;
>
> And then the constraint will be as follows:
>
> template<typename T>
> concept is_elider = T::tag_elide::value;
>
> template<typename... Params>
> requires (!( (1u==sizeof...(Params)) && (is_elider<Params> || ...) ))
> AwkwardClass(Params&&... arg) noexcept
> {
> . . .
> }
>
> The benefit of this strategy is that you can derive your own class
> from "std::elide" and change the tag from "true_type" to "false_type"
> if you want to. I don't know why anyone would ever want to do that,
> but the versatility and flexibility is there.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
std::elide is because they have their own, and changing that is
difficult.
Request a `bool std::is_elider_v<my-class>` specialization and then
have `template <typename X> concept elider =
std::is_elider_v<remove_cvref_t<X>>`.
On Mon, May 27, 2024 at 12:59 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Sat, May 25, 2024 at 6:04 PM Frederick Virchanza Gotham wrote:
> >
> > So what should be the canonical way of doing this in C++26, not just
> > for the standard library but also for programmers writing their own
> > classes?
>
>
> I'm thinking I'll go with the following strategy. The class
> "std::elide" will contain a typedef as follows:
>
> typedef std::true_type tag_elide;
>
> And then the constraint will be as follows:
>
> template<typename T>
> concept is_elider = T::tag_elide::value;
>
> template<typename... Params>
> requires (!( (1u==sizeof...(Params)) && (is_elider<Params> || ...) ))
> AwkwardClass(Params&&... arg) noexcept
> {
> . . .
> }
>
> The benefit of this strategy is that you can derive your own class
> from "std::elide" and change the tag from "true_type" to "false_type"
> if you want to. I don't know why anyone would ever want to do that,
> but the versatility and flexibility is there.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2024-05-27 15:04:04