SumType is a generic discriminated union type for modern D. It is designed to
be an improved alternative to `std.variant.Algebraic`.

Features:
  - Pattern matching, including:
    - Match-by-introspection ("if it compiles, it matches") (★)
    - Multiple dispatch (★)
  - Support for self-referential types (`This`).
  - Works with `pure`, `@safe`, `@nogc`, `nothrow`, and `immutable` (★)
  - Compatible with `-betterC` and `-dip1000` (★)
  - Zero runtime overhead compared to hand-written C
      - No heap allocation
      - Does not rely on runtime type information (`TypeInfo`) (★)

Starred features (★) are those that are missing from `Algebraic`.

With this release, SumType's public API is officially considered stable. No
breaking API changes will be made from this release forward without a major
version bump.

Improvements since 0.10.0, the last announced version:
  - Copy constructors of SumType members are now called correctly.
  - Self-referential SumTypes can now contain self-referential Algebraics, and
    vice versa.
  - SumType is now tested on Windows in addition to Linux and Mac OS X.

Links:
  - Documentation: https://pbackus.github.io/sumtype/sumtype.html
  - DUB: https://code.dlang.org/packages/sumtype
  - Github: https://github.com/pbackus/sumtype

On Sunday, 15 November 2020 at 20:05:16 UTC, Paul Backus wrote:
> SumType is a generic discriminated union type for modern D. It is designed to
> be an improved alternative to `std.variant.Algebraic`.
>
> [...]

Alright!! 👏 A 1.0.0 release! Awesome work here!

On Tuesday, 17 November 2020 at 22:14:04 UTC, aliak wrote:
> [snip]
>
> Alright!! 👏 A 1.0.0 release! Awesome work here!

Agreed.

On Sunday, 15 November 2020 at 20:05:16 UTC, Paul Backus wrote:
> SumType is a generic discriminated union type for modern D. It is designed to
> be an improved alternative to `std.variant.Algebraic`.
>
> [...]

Oh, this is actually useful 🍀

On Sunday, 15 November 2020 at 20:05:16 UTC, Paul Backus wrote:
> SumType is a generic discriminated union type for modern D. It is designed to
> be an improved alternative to `std.variant.Algebraic`.
>

Nice. Is it possible to describe how these types are represented in memory? Anyone who uses unions and wants to use these would want to know whether these types are laid out like unions or not. What is the size of the type - is it equal to the largest member?

On Tuesday, 24 November 2020 at 21:52:47 UTC, Dibyendu Majumdar wrote:
> On Sunday, 15 November 2020 at 20:05:16 UTC, Paul Backus wrote:
>> SumType is a generic discriminated union type for modern D. It is designed to
>> be an improved alternative to `std.variant.Algebraic`.
>>
>
> Nice. Is it possible to describe how these types are represented in memory? Anyone who uses unions and wants to use these would want to know whether these types are laid out like unions or not. What is the size of the type - is it equal to the largest member?

SumType uses a union internally, so the types all share the same memory. The size of the SumType is equal to the size of the union plus the size of the tag (plus padding, if necessary).

On Tuesday, 24 November 2020 at 22:26:34 UTC, Paul Backus wrote:

>> Nice. Is it possible to describe how these types are represented in memory? Anyone who uses unions and wants to use these would want to know whether these types are laid out like unions or not. What is the size of the type - is it equal to the largest member?
>
> SumType uses a union internally, so the types all share the same memory. The size of the SumType is equal to the size of the union plus the size of the tag (plus padding, if necessary).

Thanks - I was suggesting adding a description to the documentation, unless it is already there. Also an ABI specification would be helpful - what happens when a value  is passed to a C program.

On Tuesday, 24 November 2020 at 23:02:15 UTC, Dibyendu Majumdar wrote:
>
> Thanks - I was suggesting adding a description to the documentation, unless it is already there. Also an ABI specification would be helpful - what happens when a value  is passed to a C program.

Thanks for the suggestion. The documentation describes SumType as "a tagged union," which I think is enough to get the point across, but I should probably include a link to a definition in case the reader is unfamiliar with that term.

The exact memory layout and ABI of SumType is deliberately left unspecified. It's an implementation detail that client code isn't supposed to rely on. If you want to pass a SumType's value to a C function, you will first have to extract it using pattern matching.

On Wednesday, 25 November 2020 at 00:20:54 UTC, Paul Backus wrote:
>
> The exact memory layout and ABI of SumType is deliberately left unspecified. It's an implementation detail that client code isn't supposed to rely on. If you want to pass a SumType's value to a C function, you will first have to extract it using pattern matching.

For me personally it would be more helpful if the layout/ABI was fully specified. I guess other people may have different opinions. In a systems language it is always more useful to have an exact specification of what the layout will be.

On Wednesday, 25 November 2020 at 00:20:54 UTC, Paul Backus wrote:
> The exact memory layout and ABI of SumType is deliberately left unspecified. It's an implementation detail that client code isn't supposed to rely on. If you want to pass a SumType's value to a C function, you will first have to extract it using pattern matching.

Is that also true of the version being merged into Phobos?  Specifically talking about the Phobos version and not the code.dlang.org version, what might change the ABI?

An example of where someone would care would be D code with a plugin system, or even a shared library with functions that take SumType instances as parameters.