On Tuesday, 29 November 2022 at 13:21:25 UTC, rikki cattermole wrote:
>
> "sumtype Option(T) = None | Some(T);"
>
> Supporting ML-ish style syntax is a must. It gives us one liners and it helps with on boarding those with familiarity with the source material. My bet is a lot of people will prefer it when they are not worried about documenting each member.
>

I disagree, that syntax with `|` is inconsistent with every other constructs, no need to create mental gymnastic

```D
sumtype T {
}
```

works like

```D
struct T {
}
```

works like

```D
enum T {
}
```

works like

```D
class T {
}
```

works like

```D
interface T {
}
```

consistency is key



> Consider:
> 
> ```d
> SumType!(int, long, float, double) first() {
> 	return second();
> }
> 
> SumType!(int, float) second() {
> 	return typeof(return).init;
> }
> ```


Why consider? to me this looks like a mistake to allow this



About the ? query thing, why not at the end?


I'm pretty excited to finally see a proper DIP for tagged union, this feature will greatly improve my code base, specially with the way to currently designed my event system!

On 30/11/2022 7:52 AM, ryuukk_ wrote:
> On Tuesday, 29 November 2022 at 13:21:25 UTC, rikki cattermole wrote:
>>
>> "sumtype Option(T) = None | Some(T);"
>>
>> Supporting ML-ish style syntax is a must. It gives us one liners and it helps with on boarding those with familiarity with the source material. My bet is a lot of people will prefer it when they are not worried about documenting each member.
>>
> 
> I disagree, that syntax with `|` is inconsistent with every other constructs, no need to create mental gymnastic

Only within D. That is the syntax (more or less) of the ML family where this is basically from (within context).

But it isn't as inconsistent as you might think even within D.

```d
enum Foo(alias v) = v;
alias Foo(T) = T;
sumtype Foo(T) = None | T;
```

Note this would be in addition to the long form since it'll be missing features, but I fully expect a lot of sum types would be defined using this syntax because those extra features just wouldn't be needed for most uses.

>> Consider:
>>
>> ```d
>> SumType!(int, long, float, double) first() {
>>     return second();
>> }
>>
>> SumType!(int, float) second() {
>>     return typeof(return).init;
>> }
>> ```
> 
> 
> Why consider? to me this looks like a mistake to allow this

Sum types entries are a set, the first function return sum type is a superset of the second one. Why shouldn't it work? It makes perfect sense! Everything being returned is in it. Nothing is being left out, it matches!

On 11/29/2022 7:54 AM, deadalnix wrote:
> The first problem that needed to be solved is automated conversion between sum types members. Think if you are trying to run this operation that exist on A but not on B, and the sum value currently contains a B, then convert that B to an A and then run the operation.

Why does the conversion need to be automated?

   S x;
   x.A = cast(typeof(S.A))x.B;


> The second one is that it ends up replacing builtin types in the codebase by custom types, most notably dynamic arrays (which I'll call slices). Doing so de facto breaks most of the codebase in ways that cannot be easily fixed, because there is no way to have a builtin type that behave like a slice.

Can you be more specific about what doesn't work?

On 11/29/22 07:26, Walter Bright wrote:
> Go ahead, Make My Day! Destroy!
> 
> https://github.com/WalterBright/DIPs/blob/sumtypes/DIPs/1NNN-(wgb).md

I guess another point is that a precise tracing garbage collector can properly understand the sum type memory layout, which is currently impossible with library-defined types

On 11/29/2022 9:14 AM, Steven Schveighoffer wrote:
> On 11/29/22 1:26 AM, Walter Bright wrote:
>> Go ahead, Make My Day! Destroy!
>>
>> https://github.com/WalterBright/DIPs/blob/sumtypes/DIPs/1NNN-(wgb).md
> 
> In Prior work, I suggest adding [TaggedAlgebraic](https://github.com/s-ludwig/taggedalgebraic) and I also suggest reading about how it works. I find it much nicer to use than std.sumtype.
> 
> In the DIP, it says that "Member functions of field declarations are restricted the same way union member functions are." What does this mean? I can't find any information on this in the spec.
> 
> An example of what is not allowed would be helpful.
> 
> -Steve

I thought it mentioned that copy constructors, postblits, and destructors are not allowed.

On 11/29/22 21:04, Walter Bright wrote:
> On 11/29/2022 9:14 AM, Steven Schveighoffer wrote:
>> On 11/29/22 1:26 AM, Walter Bright wrote:
>>> Go ahead, Make My Day! Destroy!
>>>
>>> https://github.com/WalterBright/DIPs/blob/sumtypes/DIPs/1NNN-(wgb).md
>>
>> In Prior work, I suggest adding [TaggedAlgebraic](https://github.com/s-ludwig/taggedalgebraic) and I also suggest reading about how it works. I find it much nicer to use than std.sumtype.
>>
>> In the DIP, it says that "Member functions of field declarations are restricted the same way union member functions are." What does this mean? I can't find any information on this in the spec.
>>
>> An example of what is not allowed would be helpful.
>>
>> -Steve
> 
> I thought it mentioned that copy constructors, postblits, and destructors are not allowed.

When the tag is managed by the language, you know which of those members to call under which circumstances, so this seems like an arbitrary limitation.

On Tue, Nov 29, 2022 at 09:10:56PM +0100, Timon Gehr via Digitalmars-d wrote:
> On 11/29/22 21:04, Walter Bright wrote:
[.[..]
> > I thought it mentioned that copy constructors, postblits, and destructors are not allowed.
> 
> When the tag is managed by the language, you know which of those members to call under which circumstances, so this seems like an arbitrary limitation.

Supporting ctors, postblits, and dtors does increase the complexity of the implementation.  Perhaps that can be left as a future extension?  In any case, eventually we should support it; otherwise sumtypes will be too limited in their usefulness.


T

-- 
Philosophy: how to make a career out of daydreaming.

On 30/11/2022 9:18 AM, H. S. Teoh wrote:
> Supporting ctors, postblits, and dtors does increase the complexity of
> the implementation.

Not by enough to warrant ignoring it.

After all, all the logic already exists for structs, just gotta expand upon that and add a little more glue code specializing for sum types with a switch statement.