Proposal for design of 'scope' (Was: Re: Opportunities for D)

[deadalnix via Digitalmars-d]

I'm bugging around with a similar proposal for a while, but quite 
fail to put the last pieces in place. It goes similar in

On Thursday, 10 July 2014 at 17:04:24 UTC, H. S. Teoh via 
Digitalmars-d wrote:
>    - For function parameters, this lifetime is the scope of the 
> function
>      body.

Some kind of inout scope seem less limiting. The caller know the 
scope, the callee know that is is greater than itself. It is 
important as local variable in the outer scope of the function 
have more restricted scope and must not be assignable.

Each parameter have a DIFFERENT lifetime, but it is impossible to 
tell which one is larger from the callee perspective. Thus you 
must have a more complex lifetime definition than grater/smaller 
lifetime. Yup, when you get into the details, quantum effects 
start to arise.

>>    - An unscoped variable is regarded to have infinite 
>> lifetime.
>> 

So it is not unscoped, but I'm simply nitpicking on that one.

>>       - Since a scoped return type has its lifetime as part of 
>> its type,
>>         the type system ensures that scoped values never 
>> escape their
>>         lifetime. For example, if we are sneaky and return a 
>> pointer to
>>         an inner function, the type system will prevent 
>> leakage of the

This get quite tricky to define when you can have both this and a 
context pointer. Once again, you get into a situation where you 
have 2 non sortable lifetime to handle. And worse, you'll be 
creating values out of that mess :)

>> - Aggregates:
>> 
>>    - It's turtles all the way down: members of scoped 
>> aggregates also
>>      have scoped type, with lifetime inherited from the parent
>>      aggregate. In other words, the lifetime of the aggregate 
>> is
>>      transitive to the lifetime of its members.

Yes rule for access is transitivity. But the rule to write is 
"antitransitive". It gets tricky when you consider that a member 
variable may have to be able to "extend" the lifetime of one of 
its member.

IE a member of lifetime B in a value of lifetime A sees it 
lifetime becoming max(A, B). Considering lifetime aren't always 
sortable (as show in 2 examples), this is tricky.

This basically means that you have to define what happen for non 
sortable lifetime, and what happen for union/intersection of 
lifetime. As you see, I've banged my head quite a lot on that 
one. I'm fairly confident that this is solvable, but definitively 
require a lot of effort to iron out all the details.

>> - Passing parameters: since unscoped values are regarded to 
>> have
>>   infinite lifetime, it's OK to pass unscoped values into 
>> scoped
>>   function parameters: it's a narrowing of lifetime of the 
>> original
>>   value, which is allowed. (What's not allowed is expanding 
>> the lifetime
>>   of a scoped value.)
>> 

Get rid of the whole concept of unscopped, and you get rid of a 
whole class of redundant definition that needs to be done.

>> I'm sure there are plenty of holes in this proposal, so 
>> destroy away.
>> ;-)
>> 

Need some more iron. But I'm happy to see that some people came 
up with proposal that are close to what I had in mind.

The above mentioned detail may seems scary, but I'm confident 
these will only cause problems in a small variety of cases.

An aspect of the proposal that isn't mentioned is postblit and 
destructions. scoping will need to redefine theses.

Ultimately I love the idea and think D should go in that 
direction at some point. But now I'd prefers see things ironed 
out in general in D (@safe is a good example).