Proposing std.typecons : Optional (with PR)

FeepingCreature feepingcreature at gmail.com
Tue Jun 11 12:01:34 UTC 2019


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.

D is not a functional language, it's a multiparadigm language. It 
shouldn't be afraid to have a type that deviates from the 
functional paradigm if the functional paradigm is a bad 
metaphoric fit for the semantic message that the type expresses.


More information about the Digitalmars-d mailing list