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

[Q. Schroll]

On Wednesday, 7 April 2021 at 21:44:52 UTC, Paul Backus wrote:
> On Wednesday, 7 April 2021 at 21:31:38 UTC, Q. Schroll wrote:
>> Template type deduction alone (C++ has 4 different rule sets 
>> about type deduction) is complicated. One reason for stripping 
>> `ref` from the argument types unless they explicitly bind to 
>> `ref` parameters is that references should act like aliases:
>> ```C++
>> int i;
>> int& r = i;
>> f(i);
>> f(r);
>> ```
>> Here, `f(r)` should act the same as `f(i)` irrespective of how 
>> `f` is defined. `f` could take `int`, `int&`, `const int&`, or 
>> `T`, `const T&`, or `T&&` for some `T` that can implicitly 
>> constructed from `int`. For `int&&` or `T&`it wouldn't 
>> compile. References as type constructors are weird.
>
> References as type constructors are weird *in C++* because of 
> specific choices made by the designers of C++ (such as: 
> "references should act like aliases"). There is nothing 
> inherent to the concept of a reference type that implies this 
> kind of weirdness. D does not have to make the same choices as 
> C++, and `ref(T)` in D does not have to suffer from the issues 
> that references suffer from in C++.

As Andrei said, in C++, apart from the `decltype` exception 
(which is justified), references behave as aliases. In D, it's 
the same, apart from `__trais(isRef)` which is also justified. 
What else do you expect from a reference object? Maybe I'm 
biased, but I don't see how other solutions than C++'s would be 
better.