D perfomance

[Timon Gehr]

On 4/26/20 10:19 AM, Walter Bright wrote:
> On 4/26/2020 12:45 AM, Timon Gehr wrote:
>> On 26.04.20 04:22, Walter Bright wrote:
>>> ref a and ref b cannot refer to the same memory object.
>> Actually they can, even in @safe @live code.
> 
> Bug reports are welcome. Please tag them with the 'live' keyword in 
> bugzilla.

I can't do that because you did not agree it was a bug. According to 
your DIP and past discussions, the following is *intended* behavior:

int bar(ref int x,ref int y)@safe @live{
     x=0;
     y=1;
     return x;
}

void main()@safe{
     int x;
     import std.stdio;
     writeln(bar(x,x)); // 1
}

I have always criticized this design, but so far you have stuck to it. I 
have stated many times that the main reason why it is bad is that you 
don't actually enforce any new invariant, so @live does not enable any 
new patterns at least in @safe code.

In particular, if you start optimizing based on non-enforced and 
undocumented @live assumptions, @safe @live code will not be memory safe.

You can't optimize based on @live and preserve memory safety. Given that 
you want to preserve interoperability, this is because it is tied to 
functions instead of types. @live in its current form is useless except 
perhaps as a linting tool.