Proposing std.typecons : Optional (with PR)

[aliak]

On Tuesday, 11 June 2019 at 10:01:18 UTC, FeepingCreature wrote:
> On Tuesday, 11 June 2019 at 09:58:48 UTC, aliak wrote:
>> If we're going to put an optional type there, I would consider 
>> not copy pasting nullable as it has some other issues as well, 
>> and maybe nail the interface down properly? E.g. having an 
>> optional that's a range would be rather awesome. Have you 
>> looked at: https://code.dlang.org/packages/optional. It has a 
>> lot of other added features as well but those can be removed 
>> if they're too much.
>
> I've looked at that and I specifically disagree with the 
> decision to make it a range; that's why I didn't just 
> internally switch to dub optional. Ranges are not monads. We 
> may wish we had a concept of monads but we don't; ranges are 
> not a general replacement for any conceivable container. 
> `Optional.front` is just *weird* and unintuitive at first 
> glance. It's not a bad decision in isolation, but it doesn't 
> fit what I consider "the D style" of type design.
>
> Sorry if that explanation is too fuzzy.

The explanation is a start :)

Ranges are not monads in the strictly mathematical sense you mean 
or? Why do you say this?

You can add a .get or .value to a range as well to not have the 
weirdness. Though ranges and their .front are a central concept 
in D so it should be understood *if* option is defined as a range.

Plus, whether or not you agree ranges are/can be monads or not is 
a tangential issue to seeing an optional as a monad or a 
collection (it's not mutually exclusive). In scala for e.g. it's 
a collection (also a monad), rust implements FromIterator and 
IntoIterator, haskell adheres to foldable, applicative, 
traversable and i guess others...

I'm not saying it has to be a range either, but you lose out on 
functional composition if it's not. Or you re-implement all the 
stuff from std.range/algorithm you want as part of option's 
interface to get them.