D perfomance

[Timon Gehr]

On 27.04.20 07:40, Walter Bright wrote:
> 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.
> ...

No, it is not analogous, because only @system or @trusted code can get 
that wrong, not @safe code. @safe code itself is (supposed to be) 
verified, not trusted.

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

I understand the design. It just does not make sense. All of the code is 
annotated @safe, but if you optimize based on unverified assumptions, it 
will not be memory safe. Is the goal of @live really to undermine 
@safe's guarantees?