SumType in Phobos?

[Seb]

On Wednesday, 19 February 2020 at 08:23:57 UTC, Petar Kirov 
[ZombineDev] wrote:
> On Wednesday, 19 February 2020 at 06:52:04 UTC, Ernesto 
> Castellotti wrote:
>> [...]
>
> 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 ;)


Yes, +1 for creating a "standard" package on dub.
For now, it could even just be a "meta" package that just 
includes a few popular, well-maintained packages and maybe a 
snapshot version of all non-compiler specific modules of the 
runtime (under a different namespace).

However, this has one big gotcha: at the moment Dub and DMD 
aren't able to link two versions of a same library. So let's say 
at some point sumtype 2 gets releases and newer projects start to 
use it, then you couldn't use dependencies anymore which use the 
old sumtype 2. Not a big concern for sumtype, but in the past it 
has been a problem for more basic building blocks like e.g. the 
stdx-allocator. There's v2 and v3. Let's say your JSON dependency 
uses v2, but now you want to use an XML and that uses v3 :/

Before people ask, Go/Rust etc. allow for such a conflict 
resolution and there was a SAoC project last year, but 
unfortunately it failed.