Proposing std.typecons : Optional (with PR)

[aliak]

On Tuesday, 11 June 2019 at 12:01:34 UTC, FeepingCreature wrote:
> On Tuesday, 11 June 2019 at 11:56:01 UTC, aliak wrote:
>> On Tuesday, 11 June 2019 at 10:01:18 UTC, FeepingCreature 
>> wrote:
>>> 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.
>
> Right, my point is that in functional languages things like 
> monads or generic interfaces in general are used to compose 
> reusable containers into larger processing chains. However, I 
> see `Optional` less as a container and more as a metaphor. As a 
> metaphor, it's not "a range of elements with a length of either 
> 0 or 1", it's "a type that may be either of those type's values 
> plus 'unset'". That's not something that easily lends itself to 
> the set of verbs that are used to manipulate ranges.

It does actually. I use it like a range all the time:

arrayOfStuff
   .map!maybeParseThing
   .each!processThing;

Your argument against it being a range sounds a bit too 
philosophical. I think we should  consider the actual technical 
advantages/disadvantages of having it as a range or not. And if 
not, at least getting functions like map/flatmap/each/whatever as 
usable with optional.

I basically think a bit of thought should be put in to putting an 
optional type in the standard library instead of copying nullable 
(as mentioned, the range thing is not the only problem - another 
big one is treating null as a valid value for classes).