On Wednesday, 30 November 2022 at 09:33:54 UTC, Walter Bright wrote:
> On 11/29/2022 12:37 PM, Per Nordlöw wrote:
>> ```d
>> sumtype Result
>> {
>>      Error,
>>      int Value
>> }
>> ```
>> 
>> , is
>> 
>> ```d
>> Result res;
>> res = 25;
>> ```
>> 
>> supposed to be supported aswell?
>
> At the moment, no, should be:
>
>      res.Value = 25;
>
>
>> If so, why not
>
> I'd reframe that as why do it?
>
> On a pragmatic note, there may be multiple matches for an int in the sumtype.

I would have preferred a sumtype more similar to a functional language custom type (like in 'Elm'), where every member must be of a different type, just to allow what Per was asking.

/Paolo

On 11/30/22 04:39, Walter Bright wrote:
> On 11/29/2022 6:42 AM, Timon Gehr wrote:
>> Nice!
> 
> Wow! I expected you to eviscerate it! :-)
> ...

Well, it looks useful and would allow me to easily replace some hacky unsafe variant code I have written under time pressure before a deadline. Then it would become memory safe. However, it could be a lot more useful if it also allowed me to check that I got nothing wrong. ;)

>> I think this general design, where it behaves just like a tagged union but @safe, makes sense for D. I _really_ wish bad element access resulted in a compile-time error instead of a runtime error though.
>>
>> Basically, you could treat
>>
>> if(?s.member){
>>
>> }
>>
>> and
>>
>> assert(?s.member);
>>
>> specially, and only allow accesses to s.member if they are guarded by one of them. By default, accessing members is disallowed. The user can then choose between:
>>
>> if(?s.member){
>>      writeln(s.member);
>> }
>>
>> and
>>
>> assert(?s.member);
>> writeln(s.member);
>>
>> To either check the tag manually or opt into the runtime error very explicitly.
> 
> I expect that when a user accesses s.member, he implicitly expects it to be that member. If it isn't, then it's a program bug and hence a fatal runtime error.

I don't like fatal runtime errors. I prefer compile time errors.

> Adding an assert() in front of it is redundant.
> ...

It's not redundant if it is a compile-time error by default. The explicit assert is to opt into the runtime error, but normally I'd like the compiler to check correct element access during compile time for my sumtypes. Runtime errors that could have easily been catched at compile time make the feature less useful than it can be. For me, type checking case analysis during compile time is one of the main selling points of sum types.

> 
>> I think catching errors early during type checking is one of the most compelling things about sum types in other languages, and it would be great if D could get that in some way. The analysis does not have to be particularly sophisticated. In particular, no control flow analysis is required.
> 
> The compiler could do:
> 
>      writeln(s.a);
>      writeln(s.b); // compile time error
> 
> with data flow analysis, because if all paths to the second use go through reading s.a, then s.b could not possibly be valid. It would be similar to:
> 
>      if (x == 0)
>      {
>          if (x == 1) deadCode();
>      }
> 
> which currently dmd does not do.

I want a compile time error for every wrong access. Maybe it will give compile time errors for accesses that are correct. In those cases I can either rewrite my code to make it easier to spot that it is actually right or I can add an explicit assert to document that the program might crash there in case there is a mistake.

On 11/30/22 04:53, Walter Bright wrote:
> 
> 
>> - in particular, it would be nice to provide access to the associated enumeration and the tag, e.g. for Result above, there could be an automatically generated enum like this:
>>
>> enum Result{
>>      error,
>>      value,
>> }
>>
>> Then you could do something like:
>>
>> final switch(tag(result)) {
>>      case Tag!Result.error: ...
>>      case Tag!Result.value: ...
>> }
>> This way, sumtype can be a drop-in replacement for existing unsafe tagged unions.
> 
> I propose a (future) match statement instead.

Why not both? It really should be possible to access the tag.

> Sumtypes and match statements are symbiotically joined at the hip. I realize this proposal is somewhat crippled without the match, but I didn't want to put the time into designing the match if sumtypes are DOA.
> ...

Sure, I understand! However, there has to be a way to extract the tag and statically know which member that tag corresponds to. Otherwise built-in sumtypes don't provide useful functionality that is then only accessible via library types.

> 
>> - how does it interact with type qualifiers? In particular, I guess you can have a sumtype with only immutable members and reassign them anyway?
> 
> An immutable sumtype could not have its members reassigned.

I agree. However, a mutable sumtype with `immutable` members could have its members reassigned.

On Tuesday, 29 November 2022 at 20:50:15 UTC, H. S. Teoh wrote:
> On Tue, Nov 29, 2022 at 08:37:57PM +0000, Jacob Carlborg via Digitalmars-d wrote: [...]
>> ### ABI
>> 
>> I think a section on ABI is missing. It should specify the memory layout of sumtypes, just as for existing language constructs [1].
>
> Agreed.
>
>
>> What's even more important than the memory layout is the value of the tag. Something needs to be specified in regards to the value of the tag. One needs to be able to draw some conclusions about what happens with the value if members are added, removed or reordered. Ideally the tag value of existing members should not change. These are important things when using sumtypes at ABI boundaries.
>
> You can't dynamically change a sumtype (add/remove/reorder its constituents) after the fact, because that may change their size, which implies an ABI change.

You can add members, Crystal does that all the time.

On Tuesday, 29 November 2022 at 06:26:20 UTC, Walter Bright wrote:
> Go ahead, Make My Day! Destroy!
>
> https://github.com/WalterBright/DIPs/blob/sumtypes/DIPs/1NNN-(wgb).md

Would prefer WASM and named arguments to sum types.

On Wednesday, 30 November 2022 at 20:01:47 UTC, Guillaume Piolat wrote:
> On Tuesday, 29 November 2022 at 06:26:20 UTC, Walter Bright wrote:
>> Go ahead, Make My Day! Destroy!
>>
>> https://github.com/WalterBright/DIPs/blob/sumtypes/DIPs/1NNN-(wgb).md
>
> Would prefer WASM and named arguments to sum types.

Would love to implement Web support for my engine too :D

On Wed, Nov 30, 2022 at 08:32:26PM +0000, Hipreme via Digitalmars-d wrote:
> On Wednesday, 30 November 2022 at 20:01:47 UTC, Guillaume Piolat wrote:
> > On Tuesday, 29 November 2022 at 06:26:20 UTC, Walter Bright wrote:
> > > Go ahead, Make My Day! Destroy!
> > > 
> > > https://github.com/WalterBright/DIPs/blob/sumtypes/DIPs/1NNN-(wgb).md
> > 
> > Would prefer WASM and named arguments to sum types.
> 
> Would love to implement Web support for my engine too :D

I haven't had time to look at the two existing wasm projects yet (one by Adam, and the other I forgot by who); have you tried either of them out yet?  How complete/incomplete are they?  How much can you do in them? How close/far are they to a comprehensive WASM support package for D?

I think we should evaluate what we currently have, and lay out a rough plan for how to move forward.

My ideal dream is a WASM support package (build system, helper scripts, HTML/JS generators, etc) that lets me take an existing D program, complete with GC and main(), and compile it into a web app (WASM modules + HTML + JS glue, the latter preferably completely auto-generated, that can be copied into my Apache web directory and it would Just Work(tm)), with minimal / no changes to the code itself.  Fiddly details like passing strings to/from JS, interfacing with web APIs or WASI or whatever, should just be completely automated away by scripts or build system or whatever.

Of course, I think we still have a way to go before we get to this point.  But it would be good to evaluate just where exactly we are right now wrt this ideal dream, so that we can make meaningful steps forward.


T

-- 
Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- Michael Beibl

On Tuesday, 29 November 2022 at 06:26:20 UTC, Walter Bright wrote:
> https://github.com/WalterBright/DIPs/blob/sumtypes/DIPs/1NNN-(wgb).md

What about changing the name?
To avoid yet another inconsistency.
Product type is “struct”, not “producttype”.

variant, maybe?