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
