Newbie initial comments on D language - scope

[Edward Diener]

Walter Bright wrote:
> Edward Diener wrote:
>> Now that I see where you are going, and you mentioned forwarding in 
>> your description above, I though of how boost::shared_ptr does it and 
>> I realized that the C++ 'operator ->' is the key. So I immediately 
>> looked for the equivalent in D, which would allow this to happen also, 
>> which would be an op function for the 'operator .'. But I could not 
>> find this operator supported in the D 1.0 docs. My suggestion then, if 
>> you are going to make the idea above work, is that you need to support 
>> an op function for the 'operator .' and then forwarding into the 
>> wrapped object would be simple and automatic no matter what 
>> functionality the wrapped object had.
> 
> I agree that a method for forwarding is needed to complete the job. I 
> plan on working on that after the RAII stuff is working.

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.

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.

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.

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

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."