Date: Fri, 11 Sep 2020 01:28:09 +0300
As a side-note I always wondered why statement-expressions weren't
introduced instead of a bunch-of-initializer-capabilities.
Wouldn't that have been more comprehensive and consistent?
(Not proposing, just asking.)
Eyal
On 11/09/2020 0:36, Ville Voutilainen via Std-Proposals wrote:
> On Fri, 11 Sep 2020 at 00:18, Dmitry Dmitry via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>>
>>> You can probably already have a similar outcome with:
>>>
>>> return [&] { auto It = Cont.find(42); return It == Cont.end() ? 0 :
>>> It->second; }();
>>>
>>> which is not that much longer.
>>
>>
>> Yeah... Right.
>>
>> But what about consistency (between regular if()'s and ternary operators)?
>> It just reminds me how initially, auto parameters were invented in lambdas and then they were "ported" to regular function.
>> Ditto here, initially init-statements were introduced in regular if()'s, but kind-of-forgotten in ternary operators?
>
> It's quite different. The left-hand side of a ternary operator is an
> arbitrary expression with no initial hint that a ternary operator
> will eventually follow. In the init-statement-and-condition of an
> if-statement, we know that we're going to see either
> an init-statement or a condition, we have context that tells both
> human readers and computer parsers what to expect.
> That's not the case for a ternary expression. Furthermore, it would be
> bloody weird to introduce a statement-expression
> like
> (auto It = Cont.find(42); It == Cont.end())
> only for ternary expression left-sides. Such statement-expressions are
> a thing in GCC as extensions; if you want an expression
> that contains statements, write a lambda.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=02%7C01%7Ceyalroz%40ef.technion.ac.il%7C60f2601fcbb44a14781008d855d1b940%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637353706550670448&sdata=xj%2BbX0H6RpA2ehX1TK28Ysl3TVFgzwgMlxtcCi8Pqks%3D&reserved=0
> This email is from an external mail server, be judicious when opening attachments or links
> .
>
introduced instead of a bunch-of-initializer-capabilities.
Wouldn't that have been more comprehensive and consistent?
(Not proposing, just asking.)
Eyal
On 11/09/2020 0:36, Ville Voutilainen via Std-Proposals wrote:
> On Fri, 11 Sep 2020 at 00:18, Dmitry Dmitry via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>>
>>> You can probably already have a similar outcome with:
>>>
>>> return [&] { auto It = Cont.find(42); return It == Cont.end() ? 0 :
>>> It->second; }();
>>>
>>> which is not that much longer.
>>
>>
>> Yeah... Right.
>>
>> But what about consistency (between regular if()'s and ternary operators)?
>> It just reminds me how initially, auto parameters were invented in lambdas and then they were "ported" to regular function.
>> Ditto here, initially init-statements were introduced in regular if()'s, but kind-of-forgotten in ternary operators?
>
> It's quite different. The left-hand side of a ternary operator is an
> arbitrary expression with no initial hint that a ternary operator
> will eventually follow. In the init-statement-and-condition of an
> if-statement, we know that we're going to see either
> an init-statement or a condition, we have context that tells both
> human readers and computer parsers what to expect.
> That's not the case for a ternary expression. Furthermore, it would be
> bloody weird to introduce a statement-expression
> like
> (auto It = Cont.find(42); It == Cont.end())
> only for ternary expression left-sides. Such statement-expressions are
> a thing in GCC as extensions; if you want an expression
> that contains statements, write a lambda.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=02%7C01%7Ceyalroz%40ef.technion.ac.il%7C60f2601fcbb44a14781008d855d1b940%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637353706550670448&sdata=xj%2BbX0H6RpA2ehX1TK28Ysl3TVFgzwgMlxtcCi8Pqks%3D&reserved=0
> This email is from an external mail server, be judicious when opening attachments or links
> .
>
Received on 2020-09-10 17:31:46