www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - sumtype 1.0.0

reply Paul Backus <snarwin gmail.com> writes:
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
Nov 15 2020
next sibling parent reply aliak <something something.com> writes:
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!
Nov 17 2020
parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 17 November 2020 at 22:14:04 UTC, aliak wrote:

 [snip]

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


Agreed.
Nov 17 2020
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
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 🍀
Nov 24 2020
prev sibling parent reply Dibyendu Majumdar <mobile majumdar.org.uk> writes:
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?
Nov 24 2020
parent reply Paul Backus <snarwin gmail.com> writes:
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).
Nov 24 2020
parent reply Dibyendu Majumdar <mobile majumdar.org.uk> writes:
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.
Nov 24 2020
parent reply Paul Backus <snarwin gmail.com> writes:
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.
Nov 24 2020
next sibling parent Dibyendu Majumdar <mobile majumdar.org.uk> writes:
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.
Nov 24 2020
prev sibling parent reply sarn <sarn theartofmachinery.com> writes:
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.
Nov 24 2020
parent Paul Backus <snarwin gmail.com> writes:
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 <stddef.h>

     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.
Nov 24 2020