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: Printing shortest decimal form of floating point number with Mir
On Tuesday, 22 December 2020 at 21:53:20 UTC, Walter Bright wrote: If you don't want the formatting code to be part of Phobos, I respect your choice. Why did you think I may want it? Phobos is almost not used in my work. You, Andrey, and Atila don't care about language features that have been requested for Mir or even more: rejecting DIP draft + DMD partial implementation for no real reason. Why should I care about something important for you while you act like three tsars that care only about their party for years? How come?
Re: Printing shortest decimal form of floating point number with Mir
If you don't want the formatting code to be part of Phobos, I respect your choice.
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: Printing shortest decimal form of floating point number with Mir
On Tuesday, 22 December 2020 at 09:18:25 UTC, Walter Bright wrote: On 12/21/2020 8:33 PM, 9il wrote: These functions in Phobos would make a great advertisement for Mir. How this possible? A lot more people will have Phobos than Phobos+Mir. If they are perusing the source code and see Mir contributed excellent floating point formatting code, they may have never heard of Mir but have now. "If, If Is Good" (Disney Company). From the marketing point of view, this doesn't make real sense. Then they'll be likely to be positively disposed towards using Mir because of the high quality code. Mir doesn't need a Phobos conformity mark. In many designs and implementation questions, Phobos is far behind Mir. The reality is that Phobos asks for 6K+ LOC Mir's code, while Phobos legacy in Mir's codebase is less than a quite well reworked few percentages. It's the same idea as HBO offering the first episode for free in a miniseries. People watch the first episode, like it, and then subscribe to HBO. I don't take payments from people to use Mir. They don't need to dig in Phobos source code to find it. Likely they will search GitHub or code.dlang.org to find a solution they need. Having them in Mir is already a great advertisement for Mir Since they exist in the C standard library (except for DMC :-( ) they by themselves aren't a compelling reason for someone to use Mir. They are, Mir comes with a CTFE/@nogc/nothrow formatting API and these functions are play well inside.
Re: Printing shortest decimal form of floating point number with Mir
On 12/21/2020 8:51 PM, 9il wrote: ... I just have thought maybe I have missed something and DLF helps Mir with advertising at least a bit, maybe at least with two-three tweets per year? The last time @D_Programming tweeted something about Mir was in 2016. I thought anything in D.announce got automatically tweeted. Anyhow, if you have a message that you'd like @D_Programming to tweet, please send it to Mike Parker.
Re: Printing shortest decimal form of floating point number with Mir
On 12/21/2020 8:33 PM, 9il wrote: These functions in Phobos would make a great advertisement for Mir. How this possible? A lot more people will have Phobos than Phobos+Mir. If they are perusing the source code and see Mir contributed excellent floating point formatting code, they may have never heard of Mir but have now. Then they'll be likely to be positively disposed towards using Mir because of the high quality code. It's the same idea as HBO offering the first episode for free in a miniseries. People watch the first episode, like it, and then subscribe to HBO. Having them in Mir is already a great advertisement for Mir Since they exist in the C standard library (except for DMC :-( ) they by themselves aren't a compelling reason for someone to use Mir.
