DMD 2.100, bring ont he attribute soup

[Paul Backus]

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- at 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- at live function.
* A @safe non- at 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.