www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Truly algebraic Variant and Nullable

reply 9il <ilyayaroshenko gmail.com> writes:
Truly algebraic Variant and Nullable with an order-independent 
list of types.

Nullable is defined as
```
alias Nullable(T...) = Variant!(typeof(null), T);
```

Variant and Nullable with zero types are allowed.

`void` type is supported.

Visitors are allowed to return different types.

Cyclic referencing between different variant types are supported.

More features and API:

http://mir-core.libmir.org/mir_algebraic.html

Cheers,
Ilya

The work has been sponsored by Kaleidic Associates and Symmetry 
Investments.
Nov 14 2020
next sibling parent Jack Applegame <japplegame gmail.com> writes:
On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:

 Truly algebraic Variant and Nullable with an order-independent 
 list of types.

 Nullable is defined as
 ```
 alias Nullable(T...) = Variant!(typeof(null), T);
 ```

 Variant and Nullable with zero types are allowed.

 `void` type is supported.

 Visitors are allowed to return different types.

 Cyclic referencing between different variant types are 
 supported.

 More features and API:

 http://mir-core.libmir.org/mir_algebraic.html

 Cheers,
 Ilya

 The work has been sponsored by Kaleidic Associates and Symmetry 
 Investments.


It should be in the standard library.
Nov 15 2020
prev sibling next sibling parent reply Oleg B <code.viator gmail.com> writes:
On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:

 Truly algebraic Variant and Nullable with an order-independent 
 list of types.

 Nullable is defined as
 ```
 alias Nullable(T...) = Variant!(typeof(null), T);
 ```

 Variant and Nullable with zero types are allowed.

 `void` type is supported.

 Visitors are allowed to return different types.

 Cyclic referencing between different variant types are 
 supported.

 More features and API:

 http://mir-core.libmir.org/mir_algebraic.html

 Cheers,
 Ilya

 The work has been sponsored by Kaleidic Associates and Symmetry 
 Investments.


Great library! Have you any plan to separate it from mir-core (to 
mir-algebraic for example)?
Dec 16 2020
parent reply 9il <ilyayaroshenko gmail.com> writes:
On Wednesday, 16 December 2020 at 14:54:26 UTC, Oleg B wrote:

 On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:

 Truly algebraic Variant and Nullable with an order-independent 
 list of types.

 Nullable is defined as
 ```
 alias Nullable(T...) = Variant!(typeof(null), T);
 ```

 Variant and Nullable with zero types are allowed.

 `void` type is supported.

 Visitors are allowed to return different types.

 Cyclic referencing between different variant types are 
 supported.

 More features and API:

 http://mir-core.libmir.org/mir_algebraic.html

 Cheers,
 Ilya

 The work has been sponsored by Kaleidic Associates and 
 Symmetry Investments.


 Great library! Have you any plan to separate it from mir-core 
 (to mir-algebraic for example)?


Thanks! Maybe, but mir-core is quite small itself and 
mir.algebraic is the only part that would be extended or updated 
in the near future. Other parts are quite stable. If there would 
be a strong reason to split it, we can do it.
Dec 16 2020
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 16 December 2020 at 15:58:21 UTC, 9il wrote:

 [snip]

 Thanks! Maybe, but mir-core is quite small itself and 
 mir.algebraic is the only part that would be extended or 
 updated in the near future. Other parts are quite stable. If 
 there would be a strong reason to split it, we can do it.


What about making it into a sub-package, as in here [1]?

[1] 
https://github.com/atilaneves/unit-threaded/tree/master/subpackages
Dec 16 2020
parent reply 9il <ilyayaroshenko gmail.com> writes:
On Wednesday, 16 December 2020 at 16:14:08 UTC, jmh530 wrote:

 On Wednesday, 16 December 2020 at 15:58:21 UTC, 9il wrote:

 [snip]

 Thanks! Maybe, but mir-core is quite small itself and 
 mir.algebraic is the only part that would be extended or 
 updated in the near future. Other parts are quite stable. If 
 there would be a strong reason to split it, we can do it.


 What about making it into a sub-package, as in here [1]?

 [1] 
 https://github.com/atilaneves/unit-threaded/tree/master/subpackages


It takes 0.1 seconds to compile mir-core with LDC in the release 
mode. It is almost all generic and quite fast to compile. We can, 
but dub doesn't always work well with submodules. Is there any 
other reason except compilation speed?
Dec 17 2020
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 17 December 2020 at 15:12:12 UTC, 9il wrote:

 On Wednesday, 16 December 2020 at 16:14:08 UTC, jmh530 wrote:

 On Wednesday, 16 December 2020 at 15:58:21 UTC, 9il wrote:

 [snip]

 Thanks! Maybe, but mir-core is quite small itself and 
 mir.algebraic is the only part that would be extended or 
 updated in the near future. Other parts are quite stable. If 
 there would be a strong reason to split it, we can do it.


 What about making it into a sub-package, as in here [1]?

 [1] 
 https://github.com/atilaneves/unit-threaded/tree/master/subpackages


 It takes 0.1 seconds to compile mir-core with LDC in the 
 release mode. It is almost all generic and quite fast to 
 compile. We can, but dub doesn't always work well with 
 submodules. Is there any other reason except compilation speed?


You can put it on code.dlang.org as a subPackage and people can 
download it without downloading all of mir-core. See below:

https://code.dlang.org/packages/unit-threaded
Dec 17 2020
parent 9il <ilyayaroshenko gmail.com> writes:
On Thursday, 17 December 2020 at 15:38:52 UTC, jmh530 wrote:

 On Thursday, 17 December 2020 at 15:12:12 UTC, 9il wrote:

 On Wednesday, 16 December 2020 at 16:14:08 UTC, jmh530 wrote:

 On Wednesday, 16 December 2020 at 15:58:21 UTC, 9il wrote:

 [...]


 What about making it into a sub-package, as in here [1]?

 [1] 
 https://github.com/atilaneves/unit-threaded/tree/master/subpackages


 It takes 0.1 seconds to compile mir-core with LDC in the 
 release mode. It is almost all generic and quite fast to 
 compile. We can, but dub doesn't always work well with 
 submodules. Is there any other reason except compilation speed?


 You can put it on code.dlang.org as a subPackage and people can 
 download it without downloading all of mir-core. See below:

 https://code.dlang.org/packages/unit-threaded


dub downloads the whole package if just a subpackage is required. 
The size of mir-core is less then 0.5 mb and 0.1 mb in Zip 
archive.
Dec 18 2020
prev sibling parent reply Oleg B <code.viator gmail.com> writes:
On Wednesday, 16 December 2020 at 15:58:21 UTC, 9il wrote:

 On Wednesday, 16 December 2020 at 14:54:26 UTC, Oleg B wrote:

 On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:

 Truly algebraic Variant and Nullable with an 
 order-independent list of types.

 Nullable is defined as
 ```
 alias Nullable(T...) = Variant!(typeof(null), T);
 ```

 Variant and Nullable with zero types are allowed.

 `void` type is supported.

 Visitors are allowed to return different types.

 Cyclic referencing between different variant types are 
 supported.

 More features and API:

 http://mir-core.libmir.org/mir_algebraic.html

 Cheers,
 Ilya

 The work has been sponsored by Kaleidic Associates and 
 Symmetry Investments.


 Great library! Have you any plan to separate it from mir-core 
 (to mir-algebraic for example)?


 Thanks! Maybe, but mir-core is quite small itself and 
 mir.algebraic is the only part that would be extended or 
 updated in the near future. Other parts are quite stable. If 
 there would be a strong reason to split it, we can do it.


That are you planing update? It's will be perfect if you add 
`get` overload for kind type and more work with tags [2]

like that:
```
alias TUnion = Algebraic!(
     TaggedType!(int, "count"),
     TaggedType!(string, "str")
);

auto v = TUnion("hello");

S: final switch (v.kind)
{
   static foreach (i, k; EnumMembers!(k.Kind))
     case k:
       someFunction(v.get!k); // [1] by now 
v.get!(TUnion.AllowedTypes[i])
       break S;
}

if (v.is_count) // [2]
     writeln(v.count);
```

or may be I miss this feature in docs?
Dec 16 2020
parent 9il <ilyayaroshenko gmail.com> writes:
On Wednesday, 16 December 2020 at 18:14:54 UTC, Oleg B wrote:

 On Wednesday, 16 December 2020 at 15:58:21 UTC, 9il wrote:

 On Wednesday, 16 December 2020 at 14:54:26 UTC, Oleg B wrote:

 On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:

 [...]


 Great library! Have you any plan to separate it from mir-core 
 (to mir-algebraic for example)?


 Thanks! Maybe, but mir-core is quite small itself and 
 mir.algebraic is the only part that would be extended or 
 updated in the near future. Other parts are quite stable. If 
 there would be a strong reason to split it, we can do it.


 That are you planing update? It's will be perfect if you add 
 `get` overload for kind type and more work with tags [2]

 like that:
 ```
 alias TUnion = Algebraic!(
     TaggedType!(int, "count"),
     TaggedType!(string, "str")
 );

 auto v = TUnion("hello");

 S: final switch (v.kind)
 {
   static foreach (i, k; EnumMembers!(k.Kind))
     case k:
       someFunction(v.get!k); // [1] by now 
 v.get!(TUnion.AllowedTypes[i])
       break S;
 }

 if (v.is_count) // [2]
     writeln(v.count);
 ```

 or may be I miss this feature in docs?


Get by Kind cand be added.

You can define TaggedAlgebraic [1].

It has a bit weird API with a separate array of lengths. But we 
can add another one definition option I think.

http://mir-core.libmir.org/mir_algebraic.html#TaggedVariant
Dec 17 2020
prev sibling next sibling parent reply Tobias Pankrath <tobias+dlang pankrath.net> writes:
On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:

 Truly algebraic Variant and Nullable with an order-independent 
 list of types.


Thanks for sharing it!

Could you give a (very short) explanation on why sumtype could 
not meet your requirements? I am just starting a new D project 
and have to choose between sumtype and your solution.


 The work has been sponsored by Kaleidic Associates and Symmetry 
 Investments.


Much appreciated!
Dec 20 2020
next sibling parent Oleg B <code.viator gmail.com> writes:
On Sunday, 20 December 2020 at 11:00:05 UTC, Tobias Pankrath 
wrote:

 On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:

 Truly algebraic Variant and Nullable with an order-independent 
 list of types.


 Thanks for sharing it!

 Could you give a (very short) explanation on why sumtype could 
 not meet your requirements? I am just starting a new D project 
 and have to choose between sumtype and your solution.


 The work has been sponsored by Kaleidic Associates and 
 Symmetry Investments.


 Much appreciated!


For me choose between sumtype and mir.algebraic ends when I not 
found
any solution for working with type kind [1] in sumtype. Kind 
represents in
taggedalgebraic [2] too, but it can't work in compile time 
(important for
me in current project). Also I find tagged_union [3] library, but 
it haven't
any visit [4] or match functions.


[2] https://code.dlang.org/packages/taggedalgebraic
[3] https://code.dlang.org/packages/tagged_union
[4] http://mir-core.libmir.org/mir_algebraic.html#visit
Dec 21 2020
prev sibling parent reply 9il <ilyayaroshenko gmail.com> writes:
On Sunday, 20 December 2020 at 11:00:05 UTC, Tobias Pankrath 
wrote:

 On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:

 Truly algebraic Variant and Nullable with an order-independent 
 list of types.


 Thanks for sharing it!

 Could you give a (very short) explanation on why sumtype could 
 not meet your requirements? I am just starting a new D project 
 and have to choose between sumtype and your solution.


Lets users do comparisons between libraries. Both are very good.

Some mir.algebraic features:

1. (optionally) Nullable algebraic types. Also serves as buggy 
Phobos Nullable replacement.
2. (optionally) Tagged algebraic types
3. Type list order-independent declaration
4. Feature-rich visitor handlers. For example, they can form new 
Algebraic types if the visitors return different types.
5. `void` support. This is an important brick for reflections on 
the algebra of type sets.
6. Algebraic type subsets are supported by `get`, `trustedGet`, 
`_is`, and `this` primitives. You can operate with algebraic 
subset as with the type of the original typeset. [1]
7. Members (fields and methods) reflection. Is more restrictive 
than in vibe.d implementation. It adds member reflection to an 
algebraic type if all of the types contain members with the same 
name.

Mir implements Algebra of (type) sets with reflections 
(functions) on it.

[1] https://github.com/libmir/mir-core/issues/33
Dec 21 2020
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 22.12.20 04:56, 9il wrote:

 6. Algebraic type subsets are supported by `get`, `trustedGet`, `_is`, 
 and `this` primitives. You can operate with algebraic subset as with the 
 type of the original typeset. [1]


"trustedGet" - That name smells of a safety violation. And indeed 
(compile with `-release`):

----
import mir.algebraic;
import std.stdio;
void main()  safe
{
     immutable int* x = new int(42);
     Variant!(size_t, int*) v;
     v = cast(size_t) x;
     auto p = v.trustedGet!(int*); /* uh-oh */
     *p = 13; /* mutating immutable */
     writeln(*x); /* prints "13" */
}
----

The normal `get` also violates safety by giving out references into the 
union (compile with `-preview=dip1000`):

----
import mir.algebraic;
import std.stdio;
T* ref_to_ptr(T)(ref T r)  safe { return &r; }
void main()  safe
{
     immutable int* x = new int(42);
     Variant!(size_t, int*) v;
     int** p = ref_to_ptr(v.get!(int*)); /* uh-oh */
     v = cast(size_t) x;
     **p = 13; /* mutating immutable */
     writeln(*x); /* prints "13" */
}
----

But that might be an issue with DIP1000. `ref_to_ptr` is a hint that 
something isn't right in that area.
Dec 22 2020
next sibling parent reply 9il <ilyayaroshenko gmail.com> writes:
On Tuesday, 22 December 2020 at 14:27:02 UTC, ag0aep6g wrote:

 On 22.12.20 04:56, 9il wrote:

 6. Algebraic type subsets are supported by `get`, 
 `trustedGet`, `_is`, and `this` primitives. You can operate 
 with algebraic subset as with the type of the original 
 typeset. [1]


 "trustedGet" - That name smells of a safety violation. And 
 indeed (compile with `-release`):



 The normal `get` also violates safety by giving out references 
 into the union (compile with `-preview=dip1000`):



 But that might be an issue with DIP1000. `ref_to_ptr` is a hint 
 that something isn't right in that area.


The definitions are

```
auto ref get(E)()  property return inout
auto ref trustedGet(E)()  trusted  property return inout nothrow
```

Both market with `return`.

According to the spec [1, example 2]

"Struct non-static methods marked with the return attribute 
ensure the returned reference will not outlive the struct 
instance."

The docs maybe not clear enough. `trustedGet` asserts type is 
matched, while `get` throws an exception if the type doesn't 
match.

[1] https://dlang.org/spec/function.html#return-ref-parameters
Dec 22 2020
parent reply ag0aep6g <anonymous example.com> writes:
On Tuesday, 22 December 2020 at 16:32:20 UTC, 9il wrote:

 "Struct non-static methods marked with the return attribute 
 ensure the returned reference will not outlive the struct 
 instance."


The issue isn't that the reference outlives the struct. It's that 
the reference outlives a tag change of the tagged union.


 The docs maybe not clear enough. `trustedGet` asserts type is 
 matched, while `get` throws an exception if the type doesn't 
 match.


You can't rely on an assert for  safe (unless it's 
`assert(false);`).
Dec 22 2020
parent reply 9il <ilyayaroshenko gmail.com> writes:
On Tuesday, 22 December 2020 at 16:43:30 UTC, ag0aep6g wrote:

 On Tuesday, 22 December 2020 at 16:32:20 UTC, 9il wrote:

 "Struct non-static methods marked with the return attribute 
 ensure the returned reference will not outlive the struct 
 instance."


 The issue isn't that the reference outlives the struct. It's 
 that the reference outlives a tag change of the tagged union.


If I am correct Dlang doesn't provide an instrument to validate 
it, isn't it?

What alternative is possible?

Returning it by value isn't acceptable at least because of 
performance reasons: the first target of the library is struts 
with a lot of Mir ref-counted fields.


 The docs maybe not clear enough. `trustedGet` asserts type is 
 matched, while `get` throws an exception if the type doesn't 
 match.


 You can't rely on an assert for  safe (unless it's 
 `assert(false);`).


This is why it is the market as `trusted`. It is much more 
convenient than forcing users to wrap each access with  trusted 
lambda, which feels like masochism.
Dec 22 2020
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On Tuesday, 22 December 2020 at 16:54:56 UTC, 9il wrote:

 On Tuesday, 22 December 2020 at 16:43:30 UTC, ag0aep6g wrote:


[...]

 The issue isn't that the reference outlives the struct. It's 
 that the reference outlives a tag change of the tagged union.


 If I am correct Dlang doesn't provide an instrument to validate 
 it, isn't it?

 What alternative is possible?

 Returning it by value isn't acceptable at least because of 
 performance reasons: the first target of the library is struts 
 with a lot of Mir ref-counted fields.


Mark it  system then.


 The docs maybe not clear enough. `trustedGet` asserts type is 
 matched, while `get` throws an exception if the type doesn't 
 match.


 You can't rely on an assert for  safe (unless it's 
 `assert(false);`).


 This is why it is the market as `trusted`. It is much more 
 convenient than forcing users to wrap each access with  trusted 
 lambda, which feels like masochism.


 trusted makes the exact same promise to the user as  safe.

If your method doesn't have a safe interface, don't mark it  safe 
or  trusted. Mark it  system.
Dec 22 2020
parent 9il <ilyayaroshenko gmail.com> writes:
On Tuesday, 22 December 2020 at 17:07:16 UTC, ag0aep6g wrote:

 On Tuesday, 22 December 2020 at 16:54:56 UTC, 9il wrote:

 On Tuesday, 22 December 2020 at 16:43:30 UTC, ag0aep6g wrote:


 [...]

 [...]


 If I am correct Dlang doesn't provide an instrument to 
 validate it, isn't it?

 What alternative is possible?

 Returning it by value isn't acceptable at least because of 
 performance reasons: the first target of the library is struts 
 with a lot of Mir ref-counted fields.


 Mark it  system then.


 [...]


 This is why it is the market as `trusted`. It is much more 
 convenient than forcing users to wrap each access with 
  trusted lambda, which feels like masochism.


  trusted makes the exact same promise to the user as  safe.

 If your method doesn't have a safe interface, don't mark it 
  safe or  trusted. Mark it  system.


Hmm, maybe it worth changing the API a bit. Needs to wait for 
mir-core 1.2.x thought.
Dec 22 2020
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 22 December 2020 at 16:54:56 UTC, 9il wrote:

 On Tuesday, 22 December 2020 at 16:43:30 UTC, ag0aep6g wrote:

 On Tuesday, 22 December 2020 at 16:32:20 UTC, 9il wrote:

 "Struct non-static methods marked with the return attribute 
 ensure the returned reference will not outlive the struct 
 instance."


 The issue isn't that the reference outlives the struct. It's 
 that the reference outlives a tag change of the tagged union.


 If I am correct Dlang doesn't provide an instrument to validate 
 it, isn't it?

 What alternative is possible?


The solution sumtype uses is to make opAssign  system if the 
union contains any unsafe types.
Dec 22 2020
parent 9il <ilyayaroshenko gmail.com> writes:
On Tuesday, 22 December 2020 at 19:45:43 UTC, Paul Backus wrote:

 On Tuesday, 22 December 2020 at 16:54:56 UTC, 9il wrote:

 On Tuesday, 22 December 2020 at 16:43:30 UTC, ag0aep6g wrote:

 On Tuesday, 22 December 2020 at 16:32:20 UTC, 9il wrote:

 "Struct non-static methods marked with the return attribute 
 ensure the returned reference will not outlive the struct 
 instance."


 The issue isn't that the reference outlives the struct. It's 
 that the reference outlives a tag change of the tagged union.


 If I am correct Dlang doesn't provide an instrument to 
 validate it, isn't it?

 What alternative is possible?


 The solution sumtype uses is to make opAssign  system if the 
 union contains any unsafe types.


That is interesting, I have missed it. Thanks
Dec 22 2020
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 22 December 2020 at 14:27:02 UTC, ag0aep6g wrote:

 On 22.12.20 04:56, 9il wrote:

 6. Algebraic type subsets are supported by `get`, 
 `trustedGet`, `_is`, and `this` primitives. You can operate 
 with algebraic subset as with the type of the original 
 typeset. [1]


 "trustedGet" - That name smells of a safety violation. And 
 indeed (compile with `-release`):

 ----
 import mir.algebraic;
 import std.stdio;
 void main()  safe
 {
     immutable int* x = new int(42);
     Variant!(size_t, int*) v;
     v = cast(size_t) x;
     auto p = v.trustedGet!(int*); /* uh-oh */
     *p = 13; /* mutating immutable */
     writeln(*x); /* prints "13" */
 }
 [snip]


For
v = cast(size_t) x;
I thought  safe prevented explicitly casting an immutable to a 
mutable, but the code below seems to suggest it is ok in this 
case...

void main()  safe
{
     immutable x = 32;
     auto v = cast(size_t) x;
}
Dec 22 2020
parent reply ag0aep6g <anonymous example.com> writes:
On Tuesday, 22 December 2020 at 16:53:11 UTC, jmh530 wrote:

 For
 v = cast(size_t) x;
 I thought  safe prevented explicitly casting an immutable to a 
 mutable, but the code below seems to suggest it is ok in this 
 case...

 void main()  safe
 {
     immutable x = 32;
     auto v = cast(size_t) x;
 }


It's ok because you're making a copy. Casting from immutable to 
mutable is only dangerous when altering the mutable thing would 
affect the immutable thing, as it happens with pointers and such.
Dec 22 2020
parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 22 December 2020 at 17:20:03 UTC, ag0aep6g wrote:

 On Tuesday, 22 December 2020 at 16:53:11 UTC, jmh530 wrote:

 For
 v = cast(size_t) x;
 I thought  safe prevented explicitly casting an immutable to a 
 mutable, but the code below seems to suggest it is ok in this 
 case...

 void main()  safe
 {
     immutable x = 32;
     auto v = cast(size_t) x;
 }


 It's ok because you're making a copy. Casting from immutable to 
 mutable is only dangerous when altering the mutable thing would 
 affect the immutable thing, as it happens with pointers and 
 such.


Ah, I get the error when I keep v as a pointer (or replace x with 
a cast). I had tried below and didn't have errors, but if you 
change the cast to cast(size_t*) then you get the error. Thanks 
for that.

void main()  safe
{
     immutable int* x = new int(32);
     auto v = cast(size_t) x;
     v++;
}
Dec 22 2020
prev sibling parent Paul Backus <snarwin gmail.com> writes:
On Tuesday, 22 December 2020 at 03:56:13 UTC, 9il wrote:

 On Sunday, 20 December 2020 at 11:00:05 UTC, Tobias Pankrath 
 wrote:

 On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:

 Truly algebraic Variant and Nullable with an 
 order-independent list of types.


 Thanks for sharing it!

 Could you give a (very short) explanation on why sumtype could 
 not meet your requirements? I am just starting a new D project 
 and have to choose between sumtype and your solution.


 Lets users do comparisons between libraries. Both are very good.

 Some mir.algebraic features:

 [...]

 Mir implements Algebra of (type) sets with reflections 
 (functions) on it.


It seems like in general, the philosophy of sumtype is to provide 
the minimal set of features necessary to cover all possible 
use-cases ("mechanism, not policy"), whereas the philosophy of 
mir.algebraic is to include a large number of convenience 
features out-of-the-box.

The upside of mir.algebraic's approach is that it is easier to 
get started with. The downside is that, if you later discover 
that the convenience features are not quite what you want, you 
will be stuck reimplementing them yourself anyway--and at that 
point, the built-in versions will only get in your way.

They also introduce a lot of incidental complexity to the 
library. Take a look at the documentation [1] and you'll see a 
giant table describing the subtle differences in behavior between 
12 (!) distinct accessor functions. By comparison, sumtype has 
exactly one accessor function, "match" [2], whose full behavior 
is documented in about the same amount of space.

[1] http://mir-core.libmir.org/mir_algebraic.html
[2] https://pbackus.github.io/sumtype/sumtype.match.html
Dec 22 2020
prev sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:

 Truly algebraic Variant and Nullable with an order-independent 
 list of types.

 Nullable is defined as
 ```
 alias Nullable(T...) = Variant!(typeof(null), T);
 ```

 Variant and Nullable with zero types are allowed.

 `void` type is supported.

 Visitors are allowed to return different types.

 Cyclic referencing between different variant types are 
 supported.

 More features and API:

 http://mir-core.libmir.org/mir_algebraic.html

 Cheers,
 Ilya

 The work has been sponsored by Kaleidic Associates and Symmetry 
 Investments.


I have been using SumType [1] for a while in some of my projects 
and I'm quite happy with it. The author has been very responsive 
to feedback and the quality bar of his work is definitely higher 
than that of many other D libraries (e.g. support for 
 safe/pure/ nogc/nothrow, immutable, betterC and DIP1000, etc.).

That said, I'm also a fan of your work with Mir! mir.algorithm 
(which I'm most familiar with) is a text book example of 
high-quality generic algorithm design.

How does your work compare to sumtype? Would mir.algebraic offer 
any benefits, which would make it worth switching over?

IMO, algebraic types (sum and tuple types) should be a core 
language feature part of druntime and should have have 
corresponding syntax sugar:

// Same as Tuple!(T, "open", T, "high", T, "low", T, "close"):
alias OhlcTuple(T) = (T open, T high, T low, T close);

// Same as:
// Union!(long, double, bool, typeof(null), string,
//     This[], This[string];
alias Json =
     | long
     | double
     | bool
     | typeof(null)
     | string
     | Json[]
     | Json[string];

// Syntax sugar for nullable/optional types -
// T? == Nullable!T == Union!(typeof(null), T):
alias ResponseParser = OhlcTuple!double? delegate(Json json);

If we can work together to consolidate on a single API, I think 
it would be better for the language ecosystem.

[1]: https://code.dlang.org/packages/sumtype
Dec 20 2020
next sibling parent reply Max Haughton <maxhaton gmail.com> writes:
On Sunday, 20 December 2020 at 12:32:35 UTC, Petar Kirov 
[ZombineDev] wrote:

 On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:

 [...]


 I have been using SumType [1] for a while in some of my 
 projects and I'm quite happy with it. The author has been very 
 responsive to feedback and the quality bar of his work is 
 definitely higher than that of many other D libraries (e.g. 
 support for  safe/pure/ nogc/nothrow, immutable, betterC and 
 DIP1000, etc.).

 [...]


I'm increasingly thinking these should be a language feature, it 
just seems right.
Dec 20 2020
parent sighoya <sighoya gmail.com> writes:
On Sunday, 20 December 2020 at 12:38:47 UTC, Max Haughton wrote:

 On Sunday, 20 December 2020 at 12:32:35 UTC, Petar Kirov 
 [ZombineDev] wrote:

 On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:

 [...]


 I have been using SumType [1] for a while in some of my 
 projects and I'm quite happy with it. The author has been very 
 responsive to feedback and the quality bar of his work is 
 definitely higher than that of many other D libraries (e.g. 
 support for  safe/pure/ nogc/nothrow, immutable, betterC and 
 DIP1000, etc.).

 [...]


 I'm increasingly thinking these should be a language feature, 
 it just seems right.


+1 because it would allow for implicit overload resolution
Dec 21 2020
prev sibling parent reply 9il <ilyayaroshenko gmail.com> writes:
On Sunday, 20 December 2020 at 12:32:35 UTC, Petar Kirov 
[ZombineDev] wrote:

 How does your work compare to sumtype? Would mir.algebraic 
 offer any benefits, which would make it worth switching over?


replied at
https://forum.dlang.org/post/zlphfxktclgdookqtdrc forum.dlang.org


 If we can work together to consolidate on a single API, I think 
 it would be better for the language ecosystem.


Agreed. On the other hand, my public association with a DIP would 
be a red flag and will increase the chance the DIP would be 
declined. Cooperation is better to make silently.
Dec 21 2020
parent Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 22 December 2020 at 04:09:59 UTC, 9il wrote:

 On Sunday, 20 December 2020 at 12:32:35 UTC, Petar Kirov 
 [ZombineDev] wrote:

 How does your work compare to sumtype? Would mir.algebraic 
 offer any benefits, which would make it worth switching over?


 replied at
 https://forum.dlang.org/post/zlphfxktclgdookqtdrc forum.dlang.org


 If we can work together to consolidate on a single API, I 
 think it would be better for the language ecosystem.


 Agreed. On the other hand, my public association with a DIP 
 would be a red flag and will increase the chance the DIP would 
 be declined. Cooperation is better to make silently.


What makes you think that?
Dec 22 2020