My Reference Safety System (DIP???)

[via Digitalmars-d]

On Sunday, 1 March 2015 at 19:35:57 UTC, deadalnix wrote:
> On Saturday, 28 February 2015 at 11:12:23 UTC, Marc Schütz 
> wrote:
>> Yes. Terminology is a problem here, I guess. When I talk about 
>> "the scope" of a variable, it means that only references to 
>> values can be stored there whose lifetimes are at least as 
>> large as the scope.
>>
>
> Make sure you explicit that. The variable itself has a scope, 
> and this scope is different from the scope of indirections 
> stored in the variable.
>
> Additionally, this naturally bring the question of multiple 
> indirection in a variable (for a struct for instance).

Access to a struct member itself is not actually indirection, 
because the member is inside the structs memory. When we take the 
address of a member, we therefore know its lifetime statically: 
it's the lifetime of the struct variable.

For accesses through a pointer (slice, etc.) one level deep, we 
also know some information about the destination's lifetime 
(that's what I'm calling scope) by looking at the return 
annotations (whether inferred or explicit), which the caller will 
enforce for us. Anything we store there needs to have a longer 
lifetime than the scope, and anything we read from there must not 
be stored where it can outlife the scope.

For deeper levels of indirection, we have no such information, so 
we must assume the worst case: we may only store things there 
that we know will live indefinitely, and what we read from there 
could cease existing immediately after the reference to it 
disappears.

>
>>> You don't cover the lifetime of the address of operation, and 
>>> I'm not how this is supposed to work in your proposal.
>>>
>>
>> It was in the examples, but it was wrong. I've corrected it: A 
>> dereference results in static lifetime.
>>
>
> Will do a second pass on the damn thing :)
>
>>>> I will also add examples how return and static annotations 
>>>> are handled.
>>>
>>> static annotation ? Seems like a bad idea and I'm sure we can 
>>> do without.
>>
>> It's only necessary if parameters of `@safe` functions are 
>> automatically scoped; then we need a way to opt-out. This is 
>> actually optional and does not affect the consistency, but I 
>> thought it is a good idea, because it reduces the overall 
>> amount of annotations. And I assume that most @safe functions 
>> are already written in a way that conforms to this. We'd need 
>> to analyze some code bases to find out whether this is 
>> actually true.
>
> Ok I misunderstood what you meant by static anotation. Sounds 
> good. Scope by default, and an optout.
>
> Problem is transition. We have a scope keyword what does it 
> become ?

It's not yet spelled out clearly enough, but by default, any 
parameters not marked as `scope` are treated as having infinite 
lifetime. This means that `scope` annotations would need to 
appear everywhere. However, they are inferred for template 
functions, together with `return` annotations, removing a large 
part of explicit annotations. (They are also always inferred for 
local variables.) For @safe functions, no inference is done, 
unless they are templates; instead, all references implicitly get 
a `scope` annotation, but no `return` annotations. The latter can 
be added manually, and we can opt-out from `scope` by using 
`static`.

Ideally most code should be @safe, and there was even talk about 
@safe by default, therefore most code shouldn't need to be 
annotated manually.

The transition can then be just like for DIP25. `scope`, `static` 
and `return` are no-ops, and can be enabled by a command-line 
switch. Later, they are enabled by default, and can be disabled 
by a switch. Finally, the switch is removed.