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).
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 ?
