Newbie initial comments on D language - scope

[Walter Bright]

Edward Diener wrote:
> Thinking about this further, why not go all the way and just provide 
> automatic support for all 'scope' objects as RAII constructs with 
> reference counted destruction. If you did that D would be the first GC 
> language to have a transparent mechanism for handling deterministic 
> destruction.

You read my mind <g>. But I wanted to see first how well proxy objects 
would work first, they may not need the extra help.

> What you are saying is that you want to allow a template struct to be a 
> wrapper for 'scope' classes. Your idea is that when the object of that 
> template class gets created the reference count is set to 1, as the 
> object of that template class gets copied or assigned to another object 
> of the same type the reference goes up, when the object is destructed 
> the reference count goes down and, if the reference count goes to 0, the 
> wrapped GC class gets destroyed.

Yes.

> Obviously in D you are tracking whenever a struct goes out of scope in 
> order to call the struct's destructor. Just as obviously you must allow 
> some copy constructor and assignment processing for a struct whenever it 
> gets copied or assigned, in order to increment the reference count.

Yes.

> If this plan is workable you could do the exact same thing at the 
> compiler level when dealing with a 'scope' object.

Yes.

> You could allow 'scope' to be specified at the class level, as you are 
> now doing, or at the object level, as you are now insisting on doing 
> when creating objects of 'scope' classes even though it is redundant ( 
> the initial reason for my OP ). But instead of being redundant, as it is 
> now, you could allow it as a way of saying that the end-user wants a 
> particular object to use scoping, ie. to be deterministically destroyed 
> when the last reference to the object goes out of scope. In this way 
> both the class designer, who knows if he may need his class to be 
> 'scope' because he knows if he needs to release a resource, and the 
> object user, who may need control to 'scope' for containers which 
> themselves are not 'scope' type but which may contain 'scope' types, 
> have full control of 'scope'
> 
> Voila ! You now have a full GC language in which both the class 
> designer, via a 'scope' class, and the object creator, via a 'scope' 
> object, has complete control over the destruction of objects. Yours 
> would be the first GC language to really solve the problem of objects 
> encapsulating non-memory resources being destroyed deterministically 
> when references to the object are no longer being used. All other GC 
> languages just gloss over the problem or maintain that it occurs so 
> rarely there is no need for anything but manual release of non-memory 
> resources ( via try/catch and specialized Dispose/Close ) or semi-manual 
> methods such as your current very limited use of 'scope'.
> 
> I hear you saying, "No I don't want to be the first GC language to solve 
> this problem especially as Java, .Net, Python, Ruby, et al.  just pretend
> it does not exist or is unimportant for practical programming and 
> besides, it is difficult to solve and I have lots of other, better 
> things to do, and finally few people will know or give me credit for it 
> anyway." But somewhere, some day, someone is going to point out this 
> flaw in GC and a solution, as I have described, will be implemented, and 
> then everyone will say, "why did we not think of this sooner". And some 
> bright person will say, "you know Walter Bright solved this years ago 
> with D."

We did think of it over a year ago, and have been laying the groundwork 
for it (wanted to get the const madness done first). This will enable D 
to be, as you say, the first language to support the triumvirate of 
explicit, automatic, and ref counted memory allocation on an equal footing.

The only question is whether the proxy struct will be easy enough to use 
to not need extra core language support:

      scope C c;

v.s.:

      Scope!(C) c;

One major consideration arguing for it to be a library feature is 
multithreading. Doing locked reference counts is slow, and needed only 
for a minority of objects. It should be selectable when you allocate the 
object whether you need it multithreaded or not.