Prototype of Ownership/Borrowing System for D

[Jab]

On Sunday, 24 November 2019 at 02:10:41 UTC, mipri wrote:
> On Saturday, 23 November 2019 at 23:40:05 UTC, Timon Gehr wrote:
>> If you want @live to mean: "do these additional checks", that
>> is fine, if people indeed want to write @system code with those
>> checks without a guarantee that their code is safe if the
>> checks pass.
>
> It's a compile-time guarantee that a class of error can't occur
> within the code so marked. If a non- at live caller makes use of
> some @live code, and introduces his own errors, they're his
> own error. @live remains in the language as a tool that the
> calling code might use to gain the same protection. As it
> expands in a code base, so shrink the places where these
> errors may still be found.

You can have use-after-free bugs happen in @live code, as a 
result of what is passed into @live functions.


void zoo() {
     int* p = cast(int*)malloc( int.sizeof * 2 );
     foo(p, p + 1);
}

@live void foo( int* p, int* q ) {
     free(p);

     *q = 10; // use after free.
}

The very error that @live is supposed to stop happens inside of 
the function on it's watch. Sure you can pass a garbage pointer 
to @safe, but the garbage pointer is created in code that isn't 
marked safe. Here it happens inside of @live itself.

I think the more dangerous thing as well is that it appears that 
it would complain that "q" is a dangling pointer. Which I assume 
it would want you to free(). But that may not be a pointer you 
want to free. So the compiler will be effectively be forcing you 
to create an error, or your code won't compile.

> I'm actually very interested in criticisms of @live (I hope 
> more people are testing it than is apparent from the posts 
> here),

I'm not too keen on testing it now. The only reason I'd see to 
test it is to find any flaws in the system, the doc provided 
illustrates that there is still a lot of known issues that need 
to be resolved first. Who knows what kind of changes will be made 
in that time.