Date: Sun, 5 Apr 2026 22:35:25 +0300
On Sun, 5 Apr 2026 at 18:57, Bjorn Reese via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On 4/5/26 16:54, Emanuel Spiridon wrote:
>
> > Yes, the proposal from 2018 is quite similar to mine, however that
> > proposal is trying to standardize Boost.Mp11 as a general purpose meta
> > programming toolkit.
> > P0949 was proposed in 2018 but was not adopted, and predates C++20
> > concepts entirely.
>
> My point was that having a type algorithm (contains) that only works
> with a dedicated type-list type rather than arbitrary templates means
> that the type algorithm has limited utility.
>
> > I am proposing the minimal building blocks needed for named, composable
> > type sets for concept constraints, without requiring users to learn a
> > full meta programming library.
>
> Another proposal that looks a lot like yours is
>
> https://wg21.link/N4115
>
> It may be worth investigating why this was not adopted.
>
> About your proposal, the subsumption example using numbers is not great,
> because we already have std::is_arithmetic for that.
>
I am sorry for having to reply twice, but I forgot to reply to this part.
A reason N4115 didn't pass could be that concept constraints weren't
standardized in 2014, my proposal is very similar by the looks of it, but
it targets a feature that exists and could be developed further.
I used the types we are familiar with to demonstrate subsumption, I didn't
believe it was necessary to use additional user defined classes for this
example
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
std-proposals_at_[hidden]> wrote:
> On 4/5/26 16:54, Emanuel Spiridon wrote:
>
> > Yes, the proposal from 2018 is quite similar to mine, however that
> > proposal is trying to standardize Boost.Mp11 as a general purpose meta
> > programming toolkit.
> > P0949 was proposed in 2018 but was not adopted, and predates C++20
> > concepts entirely.
>
> My point was that having a type algorithm (contains) that only works
> with a dedicated type-list type rather than arbitrary templates means
> that the type algorithm has limited utility.
>
> > I am proposing the minimal building blocks needed for named, composable
> > type sets for concept constraints, without requiring users to learn a
> > full meta programming library.
>
> Another proposal that looks a lot like yours is
>
> https://wg21.link/N4115
>
> It may be worth investigating why this was not adopted.
>
> About your proposal, the subsumption example using numbers is not great,
> because we already have std::is_arithmetic for that.
>
I am sorry for having to reply twice, but I forgot to reply to this part.
A reason N4115 didn't pass could be that concept constraints weren't
standardized in 2014, my proposal is very similar by the looks of it, but
it targets a feature that exists and could be developed further.
I used the types we are familiar with to demonstrate subsumption, I didn't
believe it was necessary to use additional user defined classes for this
example
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2026-04-05 19:35:37
