Unions / tagged unions?

[juliusikkala]

Do we need these in the language?

Currently, dynamic dispatching with interfaces can be used to serve a similar purpose as tagged unions, although some of it is in a work-in-progress state. These cannot serve use cases where we want a generic union; something similar to std::variant or Result<T, E>.

Here's some use cases:

• Result<T, E> could be a real type defined in the core library, instead of being an IR-only type with an explicit lowering pass.
• In scalar CPU code, it'd make C bindings cleaner, as C unions could maybe be represented as a union in Slang too. This usecase is currently served by generating property accessors that reinterpret each member into and out of common storage. This is a rare corner case though, and can already be solved, and could impose unwanted limitations on a union spec if taken into account.
• Discord discussion where such a type would've been desirable: https://discord.com/channels/1303735196696445038/1373318704372256928/1374175344243900509

[Dolkar]

My use case as mentioned in the Discord discussion is dynamic dispatch based on values previously written on the GPU. There is already a compilation API for specifying which implementations of an interface need to be taken into account for the dynamic dispatch, but this is only a good fit when the values are provided by host instead of by some other shader. In that case, it becomes important that the two separately compiled shaders agree about which implementations participate in the dispatch, what IDs each of them have and the binary representation of the union.

Currently this use case kind of works through existing functionality, but it is fairly fragile. Both the producer and consumer shaders that pass values of an interface type need to reference the same implementations, otherwise there will be a mismatch and the consumer shader could read out garbage. The implementations must either be marked as extern or there must be at least one entry point within the file that writes out a value of that type, otherwise it may not be considered for the dispatch. So this forms a strange case where the ABI of a shader silently changes based on what files have been included or what other visible entry points do.

Another downside off this approach is that it doesn't give an opportunity to intentionally exclude an implementation type from the dispatch table if we know they are not needed without using the host API. Also, the type ID for AnyValue takes up 16 bytes, even though the IDs seem to be assigned consecutively, which seems a little wasteful. There is the createDynamicObject function which lets us pack the data however we'd like, but it can't easily be used in this case because there seems to be no way to query the ID of a type from the shader itself.

I feel like a tagged union would solve all of those problems. The list of types and their IDs that it can hold are explicitly listed as part of the union type itself and the type of the tag could be user specified as well. The values could be accessed manually by querying the tag or visited if they conform to the same interface. It also plays well with #14 - the tagged union values could also be marked with some or dyn to specify if the tag is allowed to be a runtime value or not.

[csyonghe]

Yes, tagged unions (sum types) is a useful feature and Slang should eventually support it.

The current thinking is that we can just follow Swift by extending the existing enum type to also contain members (parameters) for each case value, so you can have:

enum Content
{
       TextDocument(String content),
       Image(int w, int h, void* data),
}

You can construct an enum value with:

let c = Content.TextDocument("text");

and then you can use a switch statement to handle different cases:

void print(Content c)
{
       switch (c)
       {
       case Content.TextDocument(String content):
              printf("content=%s", content);
              break;
        case Content.Image(int w, int h, void *data):
              printf(%d %d", w, h);
              break;
       }
}

[Dolkar]

A very useful part of existential types implementing an interface is that you don't need to write and maintain a switch statement every time you want to do a dispatch. I'm not sure if there would be a good way to get similar functionality with the proposed enum method.

[juliusikkala]

To add new functionality with interfaces, you need to add new member functions and implement them for everything that implements that interface, so there's similar maintenance overhead there as well.

I don't think it's easy to replicate the "group-implementations-by-type" of interfaces with enums (switches being "group-implementations-by-functionality") without introducing a lot of new syntax.

This is not a serious suggestion, implementing this would probably be really difficult for very questionable benefits, but one fun syntax springs to mind:

void print(Content.TextDocument(String content))
{
    printf("content=%s", content);
}
void print(Content.Image(int w, int h, void *data))
{
    printf(%d %d", w, h);
}

where dynamic dispatching code would be emitted on call to print depending on the value of the parameter. All possible values of Content should be required to have a matching overload. This could go as far as to allow non-enum uses like:

int factorial(int(0))
{
    return 1;
}

int factorial(int n)
{
    return factorial(n-1)*n;
}

IIRC Haskell has a similar ability.