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

[Max Haughton]

On Thursday, 8 April 2021 at 02:16:31 UTC, Andrei Alexandrescu 
wrote:
> On 4/6/21 5:14 PM, Per Nordlöw wrote:
>> On Tuesday, 6 April 2021 at 21:09:13 UTC, Paul Backus wrote:
>>> For non-copyable types. It's actually needed in both 
>>> cases--we would need DIP 1040 (or something similar) to get 
>>> rid of it.
>> 
>> So let's help Walter getting DIP-1040 accepted then. :)
>> 
>> What else is forward needed for? The doc says
>> 
>> "Forwards function arguments while keeping `out`, `ref`, and 
>> `lazy` on
>> the parameters."
>> 
>> Why can't the compiler do that for us?
>
> Because sometimes you want the usual semantics, i.e. create a 
> copy of the argument.
>
> These things are difficult to automate. I don't think a simple 
> solution exists.

I definitely agree that the "simple solution" probably doesn't 
exist, however I am kind of partial to just leaving it to the 
caller (especially for `out`, I've found in some places). It 
conflicts inside me however, because I like very plastic 
interfaces - however it kills resolution questions like you 
raised (lvalue vs. reference to lvalue) above.