Jump to page: 1 2
Thread overview
sumtype 1.0.0
Nov 17
aliak
Nov 17
jmh530
2 days ago
Imperatorn
2 days ago
Paul Backus
2 days ago
Paul Backus
2 days ago
sarn
2 days ago
Paul Backus
November 15
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
November 17
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!
November 17
On Tuesday, 17 November 2020 at 22:14:04 UTC, aliak wrote:
> [snip]
>
> Alright!! 👏 A 1.0.0 release! Awesome work here!

Agreed.
2 days ago
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 🍀
2 days ago
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?
2 days ago
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).
2 days ago
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.


2 days ago
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.
2 days ago
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.


2 days ago
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.
« First   ‹ Prev
1 2