Re: Truly algebraic Variant and Nullable
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
Re: Truly algebraic Variant and Nullable
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++;
}
Re: Truly algebraic Variant and Nullable
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.
Re: Truly algebraic Variant and Nullable
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/zlphfxktclgdookqt...@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?
Re: Truly algebraic Variant and Nullable
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.
Re: Truly algebraic Variant and Nullable
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.
Re: Truly algebraic Variant and Nullable
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.
Re: Truly algebraic Variant and Nullable
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.
Re: Truly algebraic Variant and Nullable
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;
}
Re: Truly algebraic Variant and Nullable
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);`).
Re: Truly algebraic Variant and Nullable
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
Re: Truly algebraic Variant and Nullable
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
Re: Truly algebraic Variant and Nullable
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 }
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.
Re: Truly algebraic Variant and Nullable
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/zlphfxktclgdookqt...@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.
Re: Truly algebraic Variant and Nullable
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
Re: Truly algebraic Variant and Nullable
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
Re: Truly algebraic Variant and Nullable
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. [1] http://mir-core.libmir.org/mir_algebraic.html#.TaggedVariant [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
Re: Truly algebraic Variant and Nullable
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.
Re: Truly algebraic Variant and Nullable
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
Re: Truly algebraic Variant and Nullable
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!
Re: Truly algebraic Variant and Nullable
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.
Re: Truly algebraic Variant and Nullable
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
Re: Truly algebraic Variant and Nullable
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
Re: Truly algebraic Variant and Nullable
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?
Re: Truly algebraic Variant and Nullable
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?
Re: Truly algebraic Variant and Nullable
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
Re: Truly algebraic Variant and Nullable
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.
Re: Truly algebraic Variant and Nullable
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)?
Re: Truly algebraic Variant and Nullable
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.
Truly algebraic Variant and Nullable
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.
