My Reference Safety System (DIP???)
deadalnix via Digitalmars-d
digitalmars-d at puremagic.com
Sun Mar 1 11:35:56 PST 2015
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 ?
More information about the Digitalmars-d
mailing list