Hello everyone.

Went to see what is being prepared in the new compiler and saw this
https://dlang.org/changelog/pending.html#std-sumtype

Is this realy final variant for including to phobos, not std.experimental? No way for getting tag explicitly (it's private), no way for getting type by tag, sumtype depend on order of types... I don't see any discussion about including it to phobos... Why? Nobody cares?

I think algebraic types must be in phobos, but it must be fully complited. Otherwise it not neccessary: side libs will fix some misses and we don't get unified algebraics.

For example std.json have no [de]serialization and vibe.data.json is more useful and used in many projects.

More general question: why phobos so bad structured? No way to determine what can be used without gc, that need it (other D features like betterC in the same situation). Some basic actions requires couple of std libs (std.file, std.path etc). Why something things placed in experimental will be in experimental during several years, other placed to std directly (sumtype)?

May be it's time to restructure std, and determine algorithm for place new code to it (like DIPs)?

> Is this realy final variant for including to phobos, not std.experimental? No way for getting tag explicitly (it's private), no way for getting type by tag, sumtype depend on order of types... I don't see any discussion about including it to phobos... Why? Nobody cares?


I agree. Being able to extract items by type is missing. If the incorrect type is used, it can just assert(0);
This makes it really complicated to use in @nogc, since you cannot even create delegates to change things in your scope.

On Thursday, 18 March 2021 at 14:42:03 UTC, Oleg B wrote:
> Hello everyone.
>
> Went to see what is being prepared in the new compiler and saw this
> https://dlang.org/changelog/pending.html#std-sumtype
>
> Is this realy final variant for including to phobos, not std.experimental? No way for getting tag explicitly (it's private), no way for getting type by tag, sumtype depend on order of types... I don't see any discussion about including it to phobos... Why? Nobody cares?

There was discussion on Github [1] and on the forums [2].

[1] https://github.com/dlang/phobos/pull/7702
[2] https://forum.dlang.org/thread/dkizmcporviutijhqlcs@forum.dlang.org

> May be it's time to restructure std, and determine algorithm for place new code to it (like DIPs)?

I agree that the process for adding new modules to Phobos could do with an overhaul, and that the community should be involved in some way, as it is for DIPs.

On Thursday, 18 March 2021 at 15:04:13 UTC, rm wrote:
> This makes it really complicated to use in @nogc, since you cannot even create delegates to change things in your scope.

Yes you can. There's even a unit test for this specific use-case:

https://github.com/dlang/phobos/blob/8281af7310aa876f2bdeb30fd176d952141b4c96/std/sumtype.d#L2403-L2410

On Thursday, 18 March 2021 at 14:42:03 UTC, Oleg B wrote:
> Hello everyone.
>
> Went to see what is being prepared in the new compiler and saw this
> https://dlang.org/changelog/pending.html#std-sumtype
>
> [snip]

Regardless of the other comments, it looks like the next release will be a big one.

On 18/03/2021 17:12, Paul Backus wrote:
> On Thursday, 18 March 2021 at 15:04:13 UTC, rm wrote:
>> This makes it really complicated to use in @nogc, since you cannot even create delegates to change things in your scope.
> 
> Yes you can. There's even a unit test for this specific use-case:
> 
> https://github.com/dlang/phobos/blob/8281af7310aa876f2bdeb30fd176d952141b4c96/std/sumtype.d#L2403-L2410 
> 
I stand corrected. Now I'm going to have to go back to figure what was wrong with my code back then.

I would still like to have tryMatch in @nogc.

On Thursday, 18 March 2021 at 15:08:19 UTC, Paul Backus wrote:
> [1] https://github.com/dlang/phobos/pull/7702
> [2] https://forum.dlang.org/thread/dkizmcporviutijhqlcs@forum.dlang.org

Thank for links, I don't saw these news in November.

Since sumtype will be in phobos, can you explane algorithm of [de]serialization of general Sumtype value?

In other libs it will be simple for serialization:
1. get tag -> write tag
2. switch for all tags (final switch + static foreach by enum members) -> write value

example [1] https://github.com/deviator/sbin/blob/master/source/sbin/serialize.d#L76

and deserialization:
1. read tag
2. final switch + static foreach check tag -> read typed value -> write it to algebraic variable

example [2] https://github.com/deviator/sbin/blob/master/source/sbin/deserialize.d#L189

for sumtype I see what I need make own enum (or use number) what I get through match:

auto tag = val.match!(
  (Type1 t1) => 0, // or MyOwnValTag.type1
  (Type2 t2) => 1, // or MyOwnValTag.type2
  ... etc
);

next write tag, in next match write value

how to generate this match without mixins? how to get (in general way) type from sumtype val by own tag or number for deserialization?

I think these problems have a solutions, but it more complicated (and need write more code) than use enum tags directly.

On Thursday, 18 March 2021 at 15:37:52 UTC, rm wrote:
>
> I would still like to have tryMatch in @nogc.

If -preview=dip1008 is ever implemented properly you will get this for free.

On Thursday, 18 March 2021 at 15:58:55 UTC, Oleg B wrote:
> auto tag = val.match!(
>   (Type1 t1) => 0, // or MyOwnValTag.type1
>   (Type2 t2) => 1, // or MyOwnValTag.type2
>   ... etc
> );
>
> next write tag, in next match write value
>
> how to generate this match without mixins? how to get (in general way) type from sumtype val by own tag or number for deserialization?

Something like this:

alias QualifiedTypes = CopyTypeQualifiers!(typeof(val), val.Types);
auto tag = val.match!(v => staticIndexOf!(typeof(v), QualifiedTypes));

On Thursday, 18 March 2021 at 16:11:06 UTC, Paul Backus wrote:
> Something like this:
>
> alias QualifiedTypes = CopyTypeQualifiers!(typeof(val), val.Types);
> auto tag = val.match!(v => staticIndexOf!(typeof(v), QualifiedTypes));

why it is not in library? or why tag is private?