My Reference Safety System (DIP???)
digitalmars-d at puremagic.com
Mon Mar 2 12:19:10 PST 2015
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
>> 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
>>> 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
Ideally most code should be @safe, and there was even talk about
@safe by default, therefore most code shouldn't need to be
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.
More information about the Digitalmars-d