Ferdi265 wrote:
> I suspect the handling for non-call-operator methods on lambdas isn't what we
> want.
>
> Defaulted special member functions are automatically immediate-escalating.
> That implicitly everything except the lambdas's conversion operator, I think.
> Probably the conversion operator should also be immediate-escalating. (I
> think this is a gap in the standard: the standard says the function F is
> immediate if the call operator is immediate, but it doesn't mention anything
> about the conversion operator itself.)
>
> Example:
>
> ```
> auto a = []consteval{return 3;};
> constexpr auto b = (+a)();
> ```
you're right, I was thinking there is some case not covered here, thanks for
the example.
[\[expr.const.imm\]/3](https://eel.is/c++draft/expr.const.imm#3) defines an
immediate-escalating function as either a lambda call operator, a
non-user-provided defaulted function (that isn't already `consteval`), or a
function that results from the instantiation of a templated entity defined with
`constexpr` (that isn't a prospective destructor).
>From the letter of that that doesn't cover the conversion operator from
>[\[expr.prim.lambda.closure\]/11](https://eel.is/c++draft/expr.prim.lambda#closure-11),
> since it is neither a template declared `constexpr` nor a non-user-provided
>defaulted function. It is simply defined to exist as a 'normal' member
>function by the standard.
I agree that this only makes sense if the conversion operator should also be
immediate if the call operator is immediate. Otherwise the conversion operator
of an immediate lambda would be uncallable in any context, right?
https://github.com/llvm/llvm-project/pull/232458
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
