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

[Steven Schveighoffer]

On 3/27/21 5:50 AM, Nick Treleaven wrote:
> On Saturday, 27 March 2021 at 01:06:37 UTC, Steven Schveighoffer wrote:
>> That could be possible if the Optional type lazily fetches the 
>> value/empty status, in which case now you are dealing with delegates 
>> and/or closures. I don't think this is the right path.
> 
> You are of course right that returning an optional must eagerly fetch a 
> value. I was just responding to you saying you have to check an optional 
> is empty before accessing the value - you don't.

I meant on every call to `front`. With the current system, you can avoid 
this by disabling asserts. With the proposed system, in order to 
properly construct the Optional, emptiness must be checked. The only way 
to defer this check to the user is to have Optional be lazily constructed.

-Steve