Deterministic life-time storage type

[Christophe]

Michel Fortin , dans le message (digitalmars.D:164837), a écrit :
> newsgroup. There were two problems for adoption: it makes writing 
> functions difficult (because you have to add all that scoping thing to 
> your mental model) and implementing new type modifiers is a major 
> undertaking that didn't fit with the schedule. While the second problem 
> might disappear given enough time, the first one is a hurdle.

If we choose the following defaults, the hurdle may not be that high:

 -1: function *parameters* and return value are scope by default 
(scope(in) and scope(out) in my terminology, although it is enough to 
say scope in that case),
 -2: *variable* are dynamic (= noscope = escape) when it is necessary, 
and scope when the compiler can find that they do not escape the scope.

This way, programmers don't have to worry about variable's scope, since 
they are dynamic by default. But the performance cost may not be too 
high, because most of the times the variable will be treated like scope 
since the functions that use them will be scope by defaults.

Lazy programmers only have to say when they let an argument escape the 
scope of a function. This is a good thing, because this scheme should be 
avoided, and in any case, this information should be documented.

When a scope as to be shared between parameters/return value, stating 
"inout" would adequately solve 90% of the cases or more. For the less 
than 10% left, "dynamic" and/or deep copies allows to get rid of the 
problem, if the programmer is too lazy to use scope(label) or has no 
choice.

Finally, programmers requiring efficiency can control the scope of a 
variable by declaring them explicitely scope. This way, the compiler 
will check they are not dynamic.

This is obviously non-backward-compatible. However, most of the errors 
will occur in function's signature, where the compiler can be made to 
provide adequate error messages to correct the signature quickly.

I reckon backward-compatibility issue and implementation time makes it 
very difficult to considers this before D 3.0, which is not tomorrow. I 
would really like this sort of system to be implemented in a 
medium-term, even if I think it's just dream.

-- 
Christophe Travert, 4 years too late to discuss the issue.