sumtype 1.0.0

[Paul Backus]

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.