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