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.