Truly algebraic Variant and Nullable
Paul Backus
snarwin at gmail.com
Tue Dec 22 14:46:00 UTC 2020
On Tuesday, 22 December 2020 at 03:56:13 UTC, 9il wrote:
> On Sunday, 20 December 2020 at 11:00:05 UTC, Tobias Pankrath
> wrote:
>> On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:
>>> Truly algebraic Variant and Nullable with an
>>> order-independent list of types.
>>
>> Thanks for sharing it!
>>
>> Could you give a (very short) explanation on why sumtype could
>> not meet your requirements? I am just starting a new D project
>> and have to choose between sumtype and your solution.
>>
>
> Lets users do comparisons between libraries. Both are very good.
>
> Some mir.algebraic features:
>
> [...]
>
> Mir implements Algebra of (type) sets with reflections
> (functions) on it.
It seems like in general, the philosophy of sumtype is to provide
the minimal set of features necessary to cover all possible
use-cases ("mechanism, not policy"), whereas the philosophy of
mir.algebraic is to include a large number of convenience
features out-of-the-box.
The upside of mir.algebraic's approach is that it is easier to
get started with. The downside is that, if you later discover
that the convenience features are not quite what you want, you
will be stuck reimplementing them yourself anyway--and at that
point, the built-in versions will only get in your way.
They also introduce a lot of incidental complexity to the
library. Take a look at the documentation [1] and you'll see a
giant table describing the subtle differences in behavior between
12 (!) distinct accessor functions. By comparison, sumtype has
exactly one accessor function, "match" [2], whose full behavior
is documented in about the same amount of space.
[1] http://mir-core.libmir.org/mir_algebraic.html
[2] https://pbackus.github.io/sumtype/sumtype.match.html
More information about the Digitalmars-d-announce
mailing list