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

[Per Nordlöw]

On Tuesday, 30 March 2021 at 00:51:44 UTC, Andrei Alexandrescu 
wrote:
> 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.

I'm eager to experiment with compiler diagnostics that, for a 
growing number of cases, detects calls to X.front/back and 
X.popFront/popBack when X is `empty`.

What criteria would need to be fulfilled on `X` and its range 
interface members in order for such a diagnostics to kick in?