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);`).

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;
}

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.

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.

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.

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.

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?

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.

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++;
}

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