D perfomance

[Walter Bright]

On 4/26/2020 2:52 PM, Timon Gehr wrote:
> 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.

@live's invariants rely on arguments passed to it that conform to its 
requirements. It's analogous to @safe code relying on its arguments conforming.

To get the checking here, main would have to be declared @live, too.