SumType in Phobos?
Seb
seb at wilzba.ch
Wed Feb 19 09:19:52 UTC 2020
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.
More information about the Digitalmars-d
mailing list