Motive behind !empty() with front() instead of Optional front()

[Andrei Alexandrescu]

On 4/5/21 10:14 PM, Paul Backus wrote:
> On Tuesday, 6 April 2021 at 01:47:47 UTC, Q. Schroll wrote:
>> On Friday, 26 March 2021 at 15:12:04 UTC, Paul Backus wrote:
>>> Of course the ideal would be to make `ref` itself into a type 
>>> qualifier (`ref(T)`).
>>
>> If you look at all the exceptions C++ has for its reference type 
>> constructor, you'll immediately see why Walter created `ref` as a 
>> storage class and not a type constructor. C++ reference types in many 
>> cases don't compose; e.g. `vector<int&>` isn't a thing.
>> If you really think about it, you don't need `ref` as a type 
>> constructor. Although allowing `ref` local variables wouldn't be 
>> harmful, I guess.
> 
> Here's what the generic identity function currently looks like in D:
> 
>     auto ref T identity(T)(auto ref T arg)
>     {
>         import core.lifetime: forward;
>         return forward!arg;
>     }
> 
> Here's what the generic identity function *would* look like if `ref` 
> were a type qualifier:
> 
>     T identity(T)(T arg)
>     {
>         return arg;
>     }

I'm not so sure. Complications arise when you pass an lvalue to identity 
- is it to be considered of type T or ref T? There are pros and cons to 
each, which is why C++ chose to allow both; its unprecedented 
decltype(auto) was defined especially to be part of function return type 
when it is to transport refness out.

Same class of problems have caused other anomalies in C++, such as 
decltype(identifier) and decltype((identifier)) having different types.

The case is open and hot.