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

[via Digitalmars-d]

On Friday, 11 July 2014 at 22:03:37 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> Along these lines, I'm wondering if "turtles all the way down" 
> is the
> wrong way of looking at it. Consider, for example, an n-level 
> deep
> nesting of aggregates. If obj.nest1 is const, then 
> obj.nest1.nest2.x
> must also be const, because otherwise we break the const 
> system. So
> const is transitive downwards. But if obj.nest1 is a scoped 
> reference
> type with lifetime L1, that doesn't necessarily mean 
> obj.nest1.y only
> has lifetime L1. It may be a pointer that points to an infinite 
> lifetime
> object, for example, so it's not a problem that the pointer 
> goes out of
> scope before the object pointed to. OTOH, if obj.nest1 has 
> scope L1,
> then obj itself cannot have a longer lifetime than L1, 
> otherwise we may
> access obj.nest1 after its lifetime is over. So the lifetime of
> obj.nest1 must propagate *upwards* (or outwards).

I'm not so sure about transitivity either, although I started 
with it. One reason that `const`, `immutable` and `shared` need 
to be transitive is that we can then use this fact to infer other 
properties from it, e.g. thread-safety. I don't really see such 
advantages for `scope`, but instead it would make handling 
`scope` in aggregates extremely complicated. And it wouldn't make 
much sense either IMO, because aggregates are usually defined 
somewhere else than where they are used, and often by a different 
author, too. Therefore, they come with their own ownership 
strategies, and it's simply not possible to force a different one 
onto them from the outside. For this reason, I now tend to 
intransitivity.

There also something else that became clear to me: If an 
important use case is found that requires transitivity, nothing 
is really lost. We know all the types that are involved, and we 
can check whether all references contained in them are marked as 
`scope` using introspection, even without additional compiler 
support beyond a simple trait, just as we can today check for 
things like `hasUnsharedAliasing`! Therefore, we wouldn't even 
close the doors for further improvements if we decide for 
intransitivity.