How do you safely deal with range.front?

[aliak]

On Friday, 29 December 2017 at 20:33:22 UTC, Jonathan M Davis 
wrote:
> Well, I don't know what you're really doing in code here, but 
> in general, you'd write your code in a way that it checks empty 
> and simply doesn't try to do anything with front if the range 
> is empty.

Yes, ideally, if programmers were perfect, this would work. The 
same applies to always checking null before dereferencing a 
pointer. You can of course try and make sure you always do check 
first. Or you can provide a safe way to do it in cases where you 
only want to dereference a pointer if the pointer is not null. 
Granted in some situations you want to crash as well because it 
would indeed be a bug if a pointer was null (or a range was 
empty).

Btw, it seems that phobos, or at lest some of it, has an 
assert(!empty, "Attempting to fetch the front of an empty 
filter."). I guess probably it's not everywhere so hence the 
weird behavior you say happens sometimes :(  ... ah well.

> You could wrap the range in a range that specifically returns 
> some default element when the wrapped range is empty, meaning 
> that the range would then be infinite.
>
> You could just use a wrapper function to call front and have it 
> return a Nullable or a default value if the range is empty, but 
> that wouldn't work when passing the range to other functions.
>
> You could also do something like an infinite range that simply 
> returns the same value forever no matter how often front gets 
> popped, and then you could use chain to combine your range and 
> that range into a single range that would iterate through your 
> range and then give the same element forever.
>
> Regardless, you'll have to be careful of any solution that 
> involves creating an infinite range, since while some 
> algorithms will be fine with it, others will either not compile 
> or result in an infinite loop (e.g. don't use foreach on it).
>

True, having to deal with infinite ranges will add to number of 
cases I'd have to worry about. Would prefer not to of course.

I'm going to explore the Nullable approach you mentioned a bit me 
thinks !

Also, I found this now: 
https://forum.dlang.org/post/fshlmahxfaeqtwjbjouz@forum.dlang.org 
. Seems to be what I'm looking for!

> Regardless, if you want to return an element when there isn't 
> one, you're going to have to come up with a value for that. 
> It's not something that's really going to work well generically.

The generic constructs would occur ideally before accessing 
front. If not then yes, you're correct. Passing a "safeFront", or 
any other non-range value further down the pipeline would need a 
an undo function the other end of the pipeline.