On 13/09/2024 4:55 AM, Meta wrote:
> Why is this member of operator necessary? What advantages does it have compared to matching based on type, like the current library sumtypes do? How is the following:
> ```D
> alias None = typeof(null);
> sumtype S  = None | int;
> sumtype S2 = int  | bool;
> 
> S1 s1;
> S2 s2 = s1.match {
>    (None) {
>      if (random() > 0.5)
>        return true;
>      else
>        return 2;
>    };
> 
>    (int v) {
>      return v;
>    };
> };
> ```
> 
> Improved by the member of operator?

As a proposal, it is the only one of the three that does not require a name to be provided. Both Walter and Paul require a name for each element.

The benefit of _optionally_ supporting names, is that when the type is not unique in of itself, you can make it unique by adding a name.

Consider a web form, where you would want to take an email, where it could be for personal use or business use:

```d
sumtype WebFormEmail = :DoNotContact | string personal | string business;
```

The extra name is now unique between the two, and you can have a way of saying do not contact me, just show me the white paper.

As for your approach to aliasing null to create a non-unique type, there is only so many sentinels in the language you can do that for and the type of a null is itself a valid type to be in a sumtype. The closest thing to what you are doing there is ``void`` and there is only one of them.

The type of a member of operator has a size zero, this allows eliding of the value if all of them are size zero. The type of a null is the same as a pointer, after all its a pointer.

Being able to elide the value, to get a sumtype down to the size of just its tag is VERY important for error handling. See zero-cost exceptions proposal for C++ to see why I consider us needing that.

https://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0709r0.pdf

On 13/09/2024 10:25 PM, IchorDev wrote:
> On Thursday, 12 September 2024 at 11:28:56 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> The layout of the sumtype is variable size, allowing for copy constructors, destructors and no value (if size zero).
> 
> So this would enable variable-sized stack return? Do you have any plans for how that might be implemented?
> Also this might be the only way to create a zero-sized type! (Hurray!)

It is not variable sized in that sense.

A specific sumtype would be fixed at compile time based upon the constraint set. The value you get from ``.sizeof`` is the size in assembly.

The variable size layout enables eliding aspects of it like destructors which are not used by a given constraint set.

> Also how costly do you think this version of sum types will be for compile times?

Each of the three designs require a declaration to define a sumtype.

There is no inline declarations, so I expect that all three will be at the same cost.

Mostly dependent upon the set operations.

So as long as the constraint set is kept small, shouldn't be noticeable I would think.

On 13/09/2024 11:16 PM, Nick Treleaven wrote:
> On Friday, 13 September 2024 at 09:26:16 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> The type of a member of operator has a size zero, this allows eliding of the value if all of them are size zero. The type of a null is the same as a pointer, after all its a pointer.
> 
> That's great. Otherwise you would have to define empty struct types and they would probably waste one byte of space:
> 
> ```d
> struct A {}
> struct B {}
> struct C {}
> 
> sumtype S = A | B | C;
> 
> A a; // size 1
> :X x; // size 0
> ```

I did this specifically for value type exceptions:

```d
void func() @throws(:FailToDecodeUTF);
```

Would actually be:

```d
size_t func();
```

It just so happens, that this is also a useful codegen trait for sumtypes.

If you rely on structs, you would have to solve the size zero problem and that isn't pretty.

https://github.com/rikkimax/DIPs/blob/2a80adb38ac94dd38eac61505fc3c3810b9eae10/DIPs/DIP1xxx-RC.md

I have updated the proposal to include ``__tagValues``, as this is used by my matching proposal and I had forgotten it.

I have also included Walter Bright's carry flag optimization for removing the tag.

Current: https://gist.github.com/rikkimax/35b5673554e8d15fc3710082953989fb/f52a7adbd30198e4bcda1c90db19ee369f9593a0

On 22/09/2024 10:43 PM, IchorDev wrote:
> On Thursday, 12 September 2024 at 11:28:56 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> In this proposal I propose a third sumtype design, one in which it is based upon structs.
> 
> One huge improvement would be to make the declaration syntax the same as that of structs as well. This would make it more consistent with the rest of the language, and allow conditional compilation statements, and potentially things like constructors and member functions. I suggest a `case` prefix like in Swift:
> ```d
> sumtype A{
>    version(Nullable) case :None;
>    case int, string text;
> }
> ```

I did have a similar syntax in the original version prior to this.

For the time being perhaps it would be better to leave it out.

I'll think about it.