Lifetime tracking

[Timon Gehr via Digitalmars-d]

On 03.06.2016 02:31, Walter Bright wrote:
> On 6/2/2016 4:29 PM, Timon Gehr wrote:
>> // need to know that lifetime of a ends not after lifetime of b
>> void assign(S,T)(ref S a, T b){ a = b; }
>>
>> void foo(scope int* k){
>>     void bar(){
>>         scope int* x;
>>         // need to check that lifetime of x ends not after lifetime of k
>>         assign(x,k);
>
> It'll fail to compile because T is not annotated with 'scope'.
> Annotating T with scope will then fail to compile because the assignment
> to 'a' may outlive 'b'.
> ...

There are no actual execution traces with those issues. The point is 
that you need additional annotations that make it work.

>>     }
>> }
>
>
>  > Note that it is tempting to come up with ad-hoc solutions that make
> some small finite set of examples work.
>
> If they cover the cases that matter, it's good.

Yes, but how do you establish that they do without using sound reasoning 
of the style I'm advocating? For example, there are a lot of tests for 
DMD, but bugs that matter keep being reported. This issue can be 
essentially eradicated for many relevant parts of a type system design 
by sticking to at most a handful of basic principles.

> Rust has the type system annotations you want,

We don't need to have the same annotations. We just need to be able to 
carry the same information around in the type system. I'm sure there is 
some syntax that will feel natural to D programmers.

> but Rust has a reputation for being difficult to
> write code for.

I don't think it is because it has sufficiently powerful annotations to 
write verifiably memory safe code and refactor it.

I do agree that ergonomics is an important consideration, but it should 
be optimized under the most basic constraints that a type system needs 
to fulfill. (Otherwise users will try it, get frustrated and use @system 
code.)

I assume the 'return' annotations we already have can stay and will 
cover quite some ground.