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