On Wednesday, 19 February 2020 at 12:03:52 UTC, Petar Kirov [ZombineDev] wrote:
> 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.

Yes I know the api of GitHub, but I would have liked to make it independent from those in order to make it universal.
Using git there is also the advantage of being able to use also with submodules, I also talked about it with Seb (he also wanted to do the same thing, I don't know if it came to something functional)

On Wednesday, 19 February 2020 at 12:28:18 UTC, Ernesto Castellotti wrote:
> On Wednesday, 19 February 2020 at 12:03:52 UTC, Petar Kirov [ZombineDev] wrote:
>> On Wednesday, 19 February 2020 at 11:42:38 UTC, Ernesto Castellotti wrote:
>>> [...]
>>
>> That's great!
>>
>>> [...]
>>
>> 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.
>
> Yes I know the api of GitHub, but I would have liked to make it independent from those in order to make it universal.
> Using git there is also the advantage of being able to use also with submodules, I also talked about it with Seb (he also wanted to do the same thing, I don't know if it came to something functional)

Not really sorry. Though there's this PR at dub: https://github.com/dlang/dub/pull/1798
(it completely avoids the SemVer resolution though).

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.


This is a bad idea. I survived until today without dub and I intend to avoid it in the future.

On Wednesday, 19 February 2020 at 16:31:25 UTC, Rumbu 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.
>
>
> This is a bad idea. I survived until today without dub and I intend to avoid it in the future.

As I mentioned in other posts, Phobos can and will be distributed as part of compiler releases even if it becomes a dub package. The most important thing is to separate the releases so that projects have the option to upgrade std at their own pace and not be forced to endure breaking changes in Phobos, whenever they need to upgrade their compiler.

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:
>> 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.

This is a good point, and I agree that it's important to acknowledge the downsides of having something in Phobos rather than on code.dlang.org. However, in the case of SumType, I think there's a convincing argument to be made that it, or something like it, ought to be in the standard library.

In the C++ community, certain types are regarded as "vocabulary types"--types that "provide a single lingua franca, a common language, for dealing with [their] domain." [1] The prototypical example is std::string. What's important about these types is not just that they're available, but that they're standardized. std::string isn't just one possible choice of string class, it's the *obvious* choice.

Which types benefit the most from this kind of standardization? In broad terms, types that are used for communication between different libraries or modules. These tend to be general-purpose, domain-agnostic types like strings, dynamic arrays, associative arrays, tuples, and--that's right--sum types.

I don't particularly care if SumType or some other implementation is accepted into Phobos (though of course, I prefer SumType myself), but I think it's important for there to be a sum type in D that (1) meets the quality standards of today's D programmers, and (2) is the obvious choice. Currently, SumType satisfies #1, but not #2; and Algebraic satisfies #2, but not #1.

Personally, I don't think it's possible to make a dub package "more obvious" than a standard library module, no matter how many shiny stickers you put on it. So, given that Algebraic is already in Phobos, and likely to remain there for a long time, I think the most sensible path forward is for SumType, or something like it, to be added alongside it.

[1] https://www.oreilly.com/library/view/mastering-the-c17/9781787126824/c6737dd3-47fa-4719-a459-72afac90857c.xhtml

On Wed, Feb 19, 2020 at 04:45:06PM +0000, Petar via Digitalmars-d wrote:
> On Wednesday, 19 February 2020 at 16:31:25 UTC, Rumbu 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.
> > 
> > This is a bad idea. I survived until today without dub and I intend to avoid it in the future.

I have also avoided dub except for one vibe.d project where it's unavoidable. It tries too hard to be both a package manager and a build system, but falls short of the former (compare, e.g., Cargo) and IMO sux at the latter.


> As I mentioned in other posts, Phobos can and will be distributed as part of compiler releases even if it becomes a dub package. The most important thing is to separate the releases so that projects have the option to upgrade std at their own pace and not be forced to endure breaking changes in Phobos, whenever they need to upgrade their compiler.

This is easier said than done, though.  In the past there have been numerous changes that required changes in both the compiler and Phobos to be synced with each other.  Ditto with druntime (and sometimes all 3).  Granted, such changes are infrequent, but when they do happen, there needs to be a way to coordinate them in a way that doesn't wind up horribly breaking user toolchain environments.

Having Phobos as a separate package will make this very tricky when you cannot be certain that the user is using a compatible version of Phobos with a compatible version of the compiler.  Remember how in the old days people used to have stray copies of phobos/druntime lying around their filesystem, and it would lead to obscure ICEs and other inscrutable problems that "magically" go away when they purge all copies of phobos/druntime and reinstall?  That's the kind of breakage we'd have to deal with if we went this route, except this time it will be worse because now users will say, "but I'm using the official dub version of Phobos, why is that not supported?".


T

-- 
A programming language should be a toolbox for the programmer to draw upon, not a minefield of dangerous explosives that you have to very carefully avoid touching in the wrong way.

On Wednesday, 19 February 2020 at 17:37:25 UTC, H. S. Teoh wrote:
> when you cannot be certain that the user is using a compatible version of Phobos with a compatible version of the compiler.  Remember how in the old days people used to have stray copies of phobos/druntime lying around their filesystem, and it would lead to obscure ICEs and other inscrutable problems that "magically" go away when they purge all copies of phobos/druntime and reinstall?  That's the kind of breakage we'd have to deal with if we went this route, except this time it will be worse because now users will say, "but I'm using the official dub version of Phobos, why is that not supported?".
>
>
> T

This could be solved by increasing the major version and requiring a minimum version of the compiler frontend as some libraries already do.

On Wednesday, 19 February 2020 at 17:33:11 UTC, Paul Backus wrote:
> Personally, I don't think it's possible to make a dub package "more obvious" than a standard library module, no matter how many shiny stickers you put on it. So, given that Algebraic is already in Phobos, and likely to remain there for a long time, I think the most sensible path forward is for SumType, or something like it, to be added alongside it.
>
> [1] https://www.oreilly.com/library/view/mastering-the-c17/9781787126824/c6737dd3-47fa-4719-a459-72afac90857c.xhtml

I agree to the hole post, both that we need such vocabulary types in phobos (e.g. I want all serialization libraries to 'just work' with sumtype) and that there is no better place for discoverability than phobos.

The question is how do we mature projects to a point where we can put them into phobos and that could be similar to the process I linked to.

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.
>
> [...]

A short note, as a company, we greatly prefer to work the other way round

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

I also have an alternative to std.variant.Algebraic at

https://github.com/nordlow/phobos-next/blob/master/src/nxt/variant.d

which is @safe pure nothrow @nogc when possible and doesn't rely on TypeInfo. No explicit support for @BetterC.