Re: sumtype 1.0.0
On Wednesday, 25 November 2020 at 00:56:39 UTC, sarn wrote: 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? Yes. The Phobos version is exactly the same as version 1.0.0 on code.dlang.org, except for some cosmetic changes needed to conform with the Phobos coding style. 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. The appropriate way to do this is for the D code to pass the SumType to the plugin or shared library as an opaque pointer, and to provide an extern(C) interface that can be used to interact with it. For example, if we want to expose the type `SumType!(int, const(char)*)` to our plugin/shared library as `MySumType`, we might write the following C header file: #include struct MySumType; extern size_t MySumType_sizeof; extern void MySumType_init_int(struct MySumType *, int); extern void MySumType_init_charptr(struct MySumType *, const char *); extern void MySumType_assign_int(struct MySumType*, int); extern void MySumType_assign_charptr(struct MySumType*, const char*); extern int *MySumType_peek_int(struct MySumType *); extern const char *MySumType_peek_charptr(struct MySumType *); Of course, the implementations of these functions would be in D, so they would use pattern matching internally.
Re: sumtype 1.0.0
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.
Re: sumtype 1.0.0
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.
Re: sumtype 1.0.0
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.
Re: sumtype 1.0.0
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.
Re: sumtype 1.0.0
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).
Re: sumtype 1.0.0
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?
Re: sumtype 1.0.0
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
Re: sumtype 1.0.0
On Tuesday, 17 November 2020 at 22:14:04 UTC, aliak wrote: [snip] Alright!! A 1.0.0 release! Awesome work here! Agreed.
Re: sumtype 1.0.0
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!
sumtype 1.0.0
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
