Optional and orElse: design feedback/critique?

[aliak]

On Saturday, 27 July 2019 at 16:27:53 UTC, Johannes Loher wrote:
> orElse currently has an overload that takes a callable that 
> returns a
> fallback value as template parameter. I think something like 
> this is
> needed, but it might be better to give it a different name (in 
> Java,
> Scala etc. this is called orElseGet). Other convenience 
> utilities might
> be nice, e.g. ifPresent, ifPresentOrElse, orElseThrow etc. 
> (take Java's
> Optional or Scala's Option as reference). These are all very 
> easy to
> implement and I have already done so several times when using 
> your library.

How would you find using .each over ifPresent? As for 
ifPresentOrElse, would this suffice?:

no!int.orElse!(() => log("nothing there"));

Would you prefer an explicit orElseThrow or a throw_ expression 
as proposed in a previous post?

>
> I also think that your current orElse semantics are a bit too 
> complicated: There is simply too much stuff (with slighty 
> differing behavior) in that one single function (I know, it is 
> several overloads, but the user does not care). E.g. I think 
> the overload that takes another range (or Optional or Nullable) 
> should be a seperate function because it actually has different 
> semantics. All overloads should have the same general behavior, 
> in my opinion. In Java, this function is called "or".

Alright, more for separation of orElse's functions :) I must say 
that I quite like the coalesce functionality. But I think maybe 
you and Paul might be right to separate that and make it a 
different function. Or just not do the coalescing and the user 
can be a bit more explicit as I think Paul suggested.

>
> Otherwise, I actually quite like the semantics of your library 
> (and I use it regularly). Thanks for your work!

You're welcome!