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

[Joseph Rushton Wakeling]

On Tuesday, 30 March 2021 at 00:51:44 UTC, Andrei Alexandrescu 
wrote:
> Efficiency. It would be impossible to iterate an array as a 
> range without copying each and every element thereof.

On an efficiency-related note, it's worth remembering that the 
`empty` property can be a compile-time constant (as it is e.g. 
with pseudo-random number generators), which means that in some 
cases it should be possible (at least in principle) to elide any 
`empty` checks at runtime.

I imagine there is a way to achieve the same effective outcome 
with an appropriately designed Option type or trait, but I don't 
know if that would be as straightforward as with the `empty` 
property.

> We investigated a few other possibilities, such as returning a 
> pointer to the next element or null. But that has problems 
> related to safety and escaping pointers.

This is probably a factor in Rust's decision to use Option<T>: 
its iterators over containers do use references (i.e. smart 
pointers), and this is easier option for them because of the 
stronger reference safety constraints.