On 5/27/2022 2:13 PM, deadalnix wrote:
> This is fundamentally broken. See https://forum.dlang.org/post/omcottkussnewheixydq@forum.dlang.org .
> 
> This is not salvageable.

If you can make it fail with an example, please post to bugzilla.

On 5/28/2022 4:49 PM, deadalnix wrote:
> Instead, we get "ref return scope" and the whole damn thing can only track things on the stack.

That's what @live adds.

On 5/28/2022 2:51 PM, Paul Backus wrote:
> The other big usability issue is the way `scope` works with `ref` parameters. D programmers who haven't already learned DIP 1000's rules generally expect the following two function declarations to be equivalent:
> 
>      void foo(scope int** p);
>      void bar(scope ref int* p);

Fortunately, `scope` is only subtractive, in that it subtracts from what you can do with it. Hence, the compiler detects errors in its usage.

On Sunday, 29 May 2022 at 06:01:42 UTC, Walter Bright wrote:
> On 5/28/2022 4:49 PM, deadalnix wrote:
>> Instead, we get "ref return scope" and the whole damn thing can only track things on the stack.
>
> That's what @live adds.

Unfortunately it is not possible to write @safe code that relies on @live for lifetime tracking, so its utility is extremely limited in practice.

On 5/28/2022 10:54 PM, Walter Bright wrote:
> If you can make it fail with an example, please post to bugzilla.

I see Timon already did.

On 5/29/2022 7:18 AM, Paul Backus wrote:
> Unfortunately it is not possible to write @safe code that relies on @live for lifetime tracking, so its utility is extremely limited in practice.

I don't know what you mean.

Unless you're referring to containers. I'm not well acquainted with Rust, but I think you can't write many containers there without dipping into unsafe code.

On Sunday, 29 May 2022 at 16:26:03 UTC, Walter Bright wrote:
> On 5/29/2022 7:18 AM, Paul Backus wrote:
>> Unfortunately it is not possible to write @safe code that relies on @live for lifetime tracking, so its utility is extremely limited in practice.
>
> I don't know what you mean.
>
> Unless you're referring to containers. I'm not well acquainted with Rust, but I think you can't write many containers there without dipping into unsafe code.

I explained this is an older thread about DIP 1000 and @safe. To quote my own post:

> In order for @safe or @trusted code to rely on @live's ownership invariants
> (e.g., "a non-scope pointer owns the memory it points to"), it must be
> impossible for @safe code to violate those invariants. Since @live's invariants
> are only enforced in @live functions, and @safe code is allowed to call
> non-@live functions, it follows that @safe code is allowed to violate @live's
> invariants, and therefore that those invariants cannot be relied upon by @safe
> or @trusted code.

Link: https://forum.dlang.org/post/hcogwpdyjbkcyofctler@forum.dlang.org

In order to fix this, you have to introduce restrictions on which functions can call or be called from @live functions. For example:

* A @safe @live function cannot call a non-@live function.
* A @safe non-@live function cannot call a @live function.

The end result is that "@safe D" and "@safe @live D" become mutually-exclusive language subsets. Library code written for one will not work with the other. It's a language fork in all but name.

I'm aware of this, and Timon has also brought it up.

It's this way to enable people to mix and match code, because I doubt many would even try it if it was "turtles all the way down".

On Sunday, 29 May 2022 at 20:05:42 UTC, Walter Bright wrote:
> I'm aware of this, and Timon has also brought it up.
>
> It's this way to enable people to mix and match code, because I doubt many would even try it if it was "turtles all the way down".

The entire problem is that we *cannot* mix and match @live code with @safe code.

Nobody who cares enough about memory safety to be interested in @live is going to want to give up @safe in order to use it.

On 5/29/2022 2:05 PM, Paul Backus wrote:
> The entire problem is that we *cannot* mix and match @live code with @safe code.
> 
> Nobody who cares enough about memory safety to be interested in @live is going to want to give up @safe in order to use it.

@live does not subtract any safety from @safe.