Deterministic life-time storage type

[Artur Skawina]

On 04/21/12 16:22, Christophe wrote:
> Now, this is the idea in a few words: 
> In each function signature, you can add information about whether the 
> function may keep reference to its parameters or return value. Then, 
> when you declare a variable, you can say how long you want to use that 
> variable. With these information, the compiler can check you use your 
> variables right, and use this information to destroy the variable at the 
> right time.
> 
> To do this, I'll alter the meaning of the scope, in, out and inout 
> keywords to create new storage type :
[...]
> I only gave here a few definitions, from which a whole scope system can 
> be deduced, and implemented. I've given it more thoughts, but this post 
> is long enough for now, so I will let you give me your thoughts, and 
> gladly answer your questions about subtelity that may arise, 
> feasibility, etc.

"scope", in its current meaning, should have been the default for all
function arguments. If this was the case, would introducing your scope-scopes
bring any additional benefits? (Let's ignore enforcement for now, and assume
the compiler won't let the scoped variables escape).

There was a thread some time ago on a similar topic:
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Why_I_could_not_cast_string_to_int_32126.html#N32168

Your "scope(out)" seems to be yet another incarnation of uniq/unique
(something that apparently keeps coming up over and over again).

"scope(inout)" AFAICT could be "T[] f(return T[] a) { return a[0..2]; }";
reusing the "return" keyword to mean "this argument could be returned
directly or indirectly as result". 

artur