Date: Thu, 20 Apr 2023 18:27:49 +0300
On Thu, 20 Apr 2023 at 18:09, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]> wrote:
> @Ville, I agree 100% with the "Why would we?" part, but I don't see what you mean about "new kind of lambda."
Right now, you can declare two kinds of lambdas; ones that don't have
captures, and ones that do. You can't declare
a lambda that takes its captures as constructor arguments. So that
would be a new kind of lambda.
>AIUI, there is nothing physically preventing us from giving a captureful lambda a non-explicit constructor from the types of its captures, just like we have in C++20 given a captureless lambda a non-explicit constructor from the types of its captures (i.e., a zero-argument constructor, because it has zero captures). What keeps WG21 from adding that (mis)feature is its lack of desirability, not implementability.
Of course. None of this is difficult to implement, Frederic's idea is
a syntactic sugar suggestion for defining function objects.
And yes, it doesn't cover how any of this should work for capture-defaults.
> @Ville, I agree 100% with the "Why would we?" part, but I don't see what you mean about "new kind of lambda."
Right now, you can declare two kinds of lambdas; ones that don't have
captures, and ones that do. You can't declare
a lambda that takes its captures as constructor arguments. So that
would be a new kind of lambda.
>AIUI, there is nothing physically preventing us from giving a captureful lambda a non-explicit constructor from the types of its captures, just like we have in C++20 given a captureless lambda a non-explicit constructor from the types of its captures (i.e., a zero-argument constructor, because it has zero captures). What keeps WG21 from adding that (mis)feature is its lack of desirability, not implementability.
Of course. None of this is difficult to implement, Frederic's idea is
a syntactic sugar suggestion for defining function objects.
And yes, it doesn't cover how any of this should work for capture-defaults.
Received on 2023-04-20 15:28:02