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.

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 ;)

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.

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

Phobos as a dub package?  It would be extremely interesting to distribute the STD without depending on the compiler.
The problem?  Dub ;-)

I think it will be extremely difficult to convince people to use dub, there are technical problems with dub (but this can be solved, so ok) but above all people want all working out of the box.
Having to use dub to compile every file that uses the STD I don't think it's a good idea.

Tell me if there are any details that could improve the situation

On Wednesday, 19 February 2020 at 09:19:52 UTC, Seb wrote:
> 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).
>

We could do something similar to CNCF and award projects different maturity levels based on their adoption and success [1]. We should maintain a curated list of such projects and projects could get a badge per stage.


[1] https://www.cncf.io/projects/

On Wednesday, 19 February 2020 at 10:00:55 UTC, Panke wrote:
> On Wednesday, 19 February 2020 at 09:19:52 UTC, Seb wrote:
>> 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).
>>
>
> We could do something similar to CNCF and award projects different maturity levels based on their adoption and success [1]. We should maintain a curated list of such projects and projects could get a badge per stage.
>
>
> [1] https://www.cncf.io/projects/

Yes, I think me and Seb have more or less the same thing in mind as the CNCF project structure (although I'm not too familiar with it).

On Wednesday, 19 February 2020 at 09:53:05 UTC, Ernesto Castellotti wrote:
> On Wednesday, 19 February 2020 at 08:23:57 UTC, Petar Kirov [ZombineDev] wrote:
>> 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 ;)
>
> Phobos as a dub package?  It would be extremely interesting to distribute the STD without depending on the compiler.
> The problem?  Dub ;-)
>
> I think it will be extremely difficult to convince people to use dub, there are technical problems with dub (but this can be solved, so ok) but above all people want all working out of the box.
> Having to use dub to compile every file that uses the STD I don't think it's a good idea.
>
> Tell me if there are any details that could improve the situation

Let me rephrase my suggestion, as perhaps I put way too much emphasis on Dub as the solution. I think that the basic minimum is having:
A) ability to download and use different library versions (including Phobos), independent of the compiler release
B) semantic versioning, so that any library can receive bug fixes from its dependencies while shielding users from breaking changes.

The rest is details. Yes, I think that right now the best solution to that problem is Dub as a package manager, but I also don't think that people should be forced to use it if they really don't want to. For example, we could continue bundling each compiler release with Phobos, while having it also available separately with SemVer-correct versioning model.

On Wednesday, 19 February 2020 at 09:53:05 UTC, Ernesto Castellotti wrote:
> On Wednesday, 19 February 2020 at 08:23:57 UTC, Petar Kirov [ZombineDev] wrote:
>> 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 ;)
>
> Phobos as a dub package?  It would be extremely interesting to distribute the STD without depending on the compiler.
> The problem?  Dub ;-)
>
> I think it will be extremely difficult to convince people to use dub, there are technical problems with dub (but this can be solved, so ok) but above all people want all working out of the box.
> Having to use dub to compile every file that uses the STD I don't think it's a good idea.
>
> Tell me if there are any details that could improve the situation

I forgot to add that, AFAIK most complains about Dub center around:
A) dub-registry availability
B) dub being used as a build system, in addition to being a package manager.

A) Could be addressed by:
1. Downloading packages from GitHub, GitLab, BitBucket, etc. instead of storing them on the dub-registry server (or at least have this as a fallback option)
2. Providing a copy of the list of packages in an alternative form and on alternative places (e.g. the list could be stored in git repository, mirrored across various providers)
3. Using other package registry services as backend (e.g. Dub has Maven support)

B) Is not a showstopper as people can continue using their favorite build-system, and have dub as build system be improved at the same time.

On Wednesday, 19 February 2020 at 11:10:02 UTC, Petar Kirov [ZombineDev] wrote:
> 1. Downloading packages from GitHub, GitLab, BitBucket, etc. instead of storing them on the dub-registry server (or at least have this as a fallback option)

Absolutely, I was going to modify dub to get the package sources directly from git (using the classic git clone), the problem is that dub-registry is not very documented and I don't know exactly how it works.

Also there is the problem of making dub dependent on git, I don't know if upstream would be accepted.

On Wednesday, 19 February 2020 at 11:42:38 UTC, Ernesto Castellotti wrote:
> On Wednesday, 19 February 2020 at 11:10:02 UTC, Petar Kirov [ZombineDev] wrote:
>> 1. Downloading packages from GitHub, GitLab, BitBucket, etc. instead of storing them on the dub-registry server (or at least have this as a fallback option)
>
> Absolutely, I was going to modify dub to get the package sources directly from git (using the classic git clone), the problem is that dub-registry is not very documented and I don't know exactly how it works.

That's great!

> Also there is the problem of making dub dependent on git, I don't know if upstream would be accepted.

GitHub provides an API, so you don't need to use git:
https://developer.github.com/v3/repos/contents/#get-archive-link

Other repo hosting solutions probably provide an API as well.