Date: Sun, 20 Nov 2022 10:23:38 -0500
On Sun, Nov 20, 2022 at 9:51 AM Kilian Henneberger via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hello,
>
> following two proposal got accepted for C++23:
> static operator() P1169R4
> static operator[] P2589R0
> Thanks a lot to the authors and everyone involved!
>
> I want to raise the idea of also allowing conversion functions to be static.
>
> template<auto X>
> struct ConvertsTo {
> static operator auto() { return X; }
> };
>
> I don't know, if code like this actually exists today and would benefit from my proposed change.
Can you explain in more detail how the motivations for operator() and
[] would transfer?
Also, if you're going to use the above example as a motivation, it'd
be better if you used a concrete type from the standard library (which
obviously can't be changed now, but it's still a concrete example):
`integral_constant` (and its ilk). As these are the closest we're
likely to get to `constexpr` parameters for a while, they're kind of
important. Especially with class non-type-template-parameters being
available.
Lastly, on a completely unrelated note, has anyone suggested a
"statically_invocable<T, R, Args>" concept, which is true if `T` can
be default initialized, is not a function/member pointer, and it has a
static `operator()` that can be called with the given arguments? It
would be possible to update `std::function` and its ilk to recognize
such types and not bother to even store them, simply calling the
static `operator()` as needed. The concept would be there to make it
easy for users to do the same thing.
<std-proposals_at_[hidden]> wrote:
>
> Hello,
>
> following two proposal got accepted for C++23:
> static operator() P1169R4
> static operator[] P2589R0
> Thanks a lot to the authors and everyone involved!
>
> I want to raise the idea of also allowing conversion functions to be static.
>
> template<auto X>
> struct ConvertsTo {
> static operator auto() { return X; }
> };
>
> I don't know, if code like this actually exists today and would benefit from my proposed change.
Can you explain in more detail how the motivations for operator() and
[] would transfer?
Also, if you're going to use the above example as a motivation, it'd
be better if you used a concrete type from the standard library (which
obviously can't be changed now, but it's still a concrete example):
`integral_constant` (and its ilk). As these are the closest we're
likely to get to `constexpr` parameters for a while, they're kind of
important. Especially with class non-type-template-parameters being
available.
Lastly, on a completely unrelated note, has anyone suggested a
"statically_invocable<T, R, Args>" concept, which is true if `T` can
be default initialized, is not a function/member pointer, and it has a
static `operator()` that can be called with the given arguments? It
would be possible to update `std::function` and its ilk to recognize
such types and not bother to even store them, simply calling the
static `operator()` as needed. The concept would be there to make it
easy for users to do the same thing.
Received on 2022-11-20 15:25:39