www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - SumType in Phobos?

reply Ernesto Castellotti <erny.castell gmail.com> writes:
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.
Feb 18 2020
next sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
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 ;)
Feb 19 2020
next sibling parent reply Seb <seb wilzba.ch> writes:
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.
Feb 19 2020
parent reply Panke <tobias pankrath.net> writes:
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/
Feb 19 2020
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
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).
Feb 19 2020
prev sibling next sibling parent reply Ernesto Castellotti <erny.castell gmail.com> writes:
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
Feb 19 2020
next sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
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.
Feb 19 2020
prev sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
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.
Feb 19 2020
parent reply Ernesto Castellotti <erny.castell gmail.com> writes:
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.
Feb 19 2020
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
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.
Feb 19 2020
parent reply Ernesto Castellotti <erny.castell gmail.com> writes:
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)
Feb 19 2020
parent Seb <seb wilzba.ch> writes:
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).
Feb 19 2020
prev sibling next sibling parent reply Rumbu <rumbu rumbu.ro> writes:
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.
Feb 19 2020
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
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.
Feb 19 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Feb 19 2020
parent Panke <tobias pankrath.net> writes:
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.
Feb 19 2020
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
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, 



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
Feb 19 2020
parent Panke <tobias pankrath.net> writes:
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.
Feb 20 2020
prev sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
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
Feb 20 2020
prev sibling parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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.
Feb 20 2020
next sibling parent Mathias Lang <pro.mathias.lang gmail.com> writes:
On Thursday, 20 February 2020 at 16:08:43 UTC, Per Nordlöw 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


 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.


Fairly sad how common of a need it is: 
https://github.com/Geod24/minivariant#minivariant-simple-focused-variant-library
Feb 20 2020
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 20 February 2020 at 16:08:43 UTC, Per Nordlöw 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


 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.


This is missing what I consider the most important feature of 
Algebraic and SumType, which is the ability to switch on the type 
index with compile-time exhaustiveness checking (i.e., `visit` or 
`match`).

The amount of  trusted code is also a red flag. I've already 
found one mistake in it [1], which means there are probably at 
least a couple more that I didn't catch.

[1] 
https://github.com/nordlow/phobos-next/blob/master/src/nxt/variant.d#L226-L228
Feb 20 2020
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Thursday, 20 February 2020 at 17:14:13 UTC, Paul Backus wrote:

 The amount of  trusted code is also a red flag. I've already 
 found one mistake in it [1], which means there are probably at 
 least a couple more that I didn't catch.

 [1] 
 https://github.com/nordlow/phobos-next/blob/master/src/nxt/variant.d#L226-L228


I see now that the private function `as` should be qualified as 
 system.

Is this the mistake you are thinking about?
Feb 20 2020
parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 20 February 2020 at 17:40:46 UTC, Per Nordlöw wrote:

 On Thursday, 20 February 2020 at 17:14:13 UTC, Paul Backus 
 wrote:

 The amount of  trusted code is also a red flag. I've already 
 found one mistake in it [1], which means there are probably at 
 least a couple more that I didn't catch.

 [1] 
 https://github.com/nordlow/phobos-next/blob/master/src/nxt/variant.d#L226-L228


 I see now that the private function `as` should be qualified as 
  system.

 Is this the mistake you are thinking about?


In the `else` branch of the `static if` statement, if `T` has 
both a copy constructor and a destructor, the copy constructor is 
skipped but the destructor will still be called.
Feb 20 2020
parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Thursday, 20 February 2020 at 18:23:45 UTC, Paul Backus wrote:

 In the `else` branch of the `static if` statement, if `T` has 
 both a copy constructor and a destructor, the copy constructor 
 is skipped but the destructor will still be called.


I see. Thanks. I'll consider removing the template flag 
`memoryPacked`.
Feb 21 2020