# Re: Initialisers in ternary operators

From: Eyal Rozenberg <eyalroz_at_[hidden]>
Date: Fri, 11 Sep 2020 01:28:09 +0300
As a side-note I always wondered why statement-expressions weren't

Wouldn't that have been more comprehensive and consistent?

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]