SumType in Phobos?

[Petar]

On Wednesday, 19 February 2020 at 06:52:04 UTC, Ernesto 
Castellotti wrote:
> How about including SumType 
> (https://github.com/pbackus/sumtype) in Phobos?
>
> We know that std.variant.Algebraic has problems (nogc, nothrow 
> etc), SumType would be a wonderful solution to provide a tagged 
> union in the std.
>
> In my opinion it could be put without too many changes in 
> std.experimental.sumtype, it already has unittest and good 
> documentation.
>
> I think it's a good starting point to start modernizing phobos 
> to make it even more functional and suitable for everything.

I use SumType in my projects and it is great! However the last 
thing I wish for is for it to be part of the standard library (at 
least in the current status quo) as this will limit bug fix 
releases to once per month and feature releases once every two 
months.

I sympathize with the intention of "standardizing" on 
high-quality API, replacing existing suboptimal designs, etc., 
however the current release model of Phobos is bad and shouldn't 
be replicated. Tying the release of libraries to the release of 
the compiler+runtime makes no sense to me.

With dub I can use any library with any supported compiler. With 
Phobos I'm tied to the lowest common denominator between all the 
compilers I need to support. If I need to use GDC to target a 
more niche architecture (not supported by LDC) it probably means 
that I'm stuck with Phobos 2.076 for some time (and of course, 
only some bits of Phobos, as probably not all will work and this 
niche architecture yet).

This situation in the last 2-3 years has improved significantly, 
but before LDC was also lagging behind dmd and that meant that 
std.experimental.{logging,allocator} we're available only with 
DMD if you used them from Phobos.

std.experimental.logging was initially a dub package and many 
continued using as such (until at least 1 year after it was 
merged in Phobos).

std.experimental.allocator was not available as a dub package, 
but it was forked quite quickly and put on code.dlang.org. There 
several reason why this was necessary:
1. People using LDC/GDC didn't want to wait months or years 
(literally in case of GDC) before they could use it.
2. People couldn't afford to wait months for bug fixes. (Back 
then D releases were not so regular as they are today.)
3. Some time later (like 2-3+ years after it was merged) Andrei 
and others needed to make breaking changes to the API, while many 
projects were already using it. Andrei insisted that code in 
std.experimental was meant to be changed (at least until it is 
moved out of the experimental namespace) and that projects that 
needed stability, shouldn't have been using it in the first place.

For example, if today someone notices that vibe.d is using 
allocators and that a performance optimization there could yield 
noticable performance increase in vibe.d applications, and they 
decide to make a pull request to Phobos, basically their efforts 
would be futile as vibe.d is instead using the dub fork.

In addition, the master branch of the dub allocators fork 
contains BetterC improvements not present in the Phobos version.

The author of std.experimental.ndslice removed it from Phobos and 
ever since it has been available from dub and
https://github.com/libmir/mir-algorithm. There have been a couple 
of new major releases (coupled with breaking changes) and that 
hasn't been a problem, since with dub your not forces to migrate 
to a newer version of the library, whenever you want (or need to) 
upgrade your compiler.

In summary, I believe that Phobos needs to grow up and break free 
from the compiler releases and go become a dub package. Then I 
see no reason why Phobos should not adopt SumType - it will be 
just one line of code in its dub.json/dub.sdl ;)