D perfomance
Timon Gehr
timon.gehr at gmx.ch
Mon Apr 27 14:26:50 UTC 2020
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?
More information about the Digitalmars-d
mailing list