Newbie initial comments on D language - scope

[Christopher Wright]

Walter Bright wrote:
> Edward Diener wrote:
>>> It will be required as any user could declare an object instance as 
>>> 'scope', and so any separately compiled code must anticipate that.
>> I agree in the sense that every object may need to carry an extra 
>> reference count with it even though it will not be used for the vast 
>> majority of objects, which will be GC. I do not view this as an issue.
> 
> It's a very serious issue, as it essentially negates much of the 
> advantage of general gc. For one example, you'll have to give up 
> interior pointers.
> 
>>> It's just that if any object could be scoped based on a runtime test, 
>>> that then you've got to insert that test at every assignment, copy 
>>> construction, and scope exit. You've got all the overhead of RC.
>> Yes, agreed. There will be overhead to deal with 'scope' objects. 
> 
> It will be needed for *every* gc object, too. And not just the 
> allocation for the reference count, the test has to be executed every time.
> 
>> However you already have some overhead dealing with stack variables, 
>> and so has C++ for its existence at the end of each scope and it sure 
>> does not make C++ slower than most GC systems.
> 
> If reference counting worked that well, there would be no push to add gc 
> to C++0x.
> 
> 
>> I can not say too strongly that if RAII, via 'scope', is to work in D 
>> or any other GC language, the end-user should be as oblivious as 
>> possible to it working automatically. This means that class designer, 
>> who surely must know whether objects of their class need RAII, tells 
>> the compiler that his type is 'scope' and the end-user proceeds to use 
>> objects of that type just as if he would use normal GC objects.
>>
>> Otherwise you are creating a bifurcated system which does the end-user 
>> no good. Not only must the end user know something in advance about 
>> the inner workings of a class ( that it needs RAII ) when the class 
>> designer already knows it, but he must also use a separate notation to 
>> deal with objects of that class.
> 
> For those cases, all the class designer needs to do is present to the 
> user the struct wrapper for the class, not the class itself.
> 
> 
>>> Then you have the problem that all generated code that manipulates 
>>> any object must insert all the rc machinery for that object, just in 
>>> case some user somewhere instantiates it as 'scope'.
>>
>> It needs to have inserted for it the mechanism which determines 
>> whether that object is a 'scope' object or not. It probably needs the 
>> extra int for possible reference counting. Other than that I do not 
>> see what other machinery is needed for normal GC objects.
> 
> Consider:
> 
> void foo(C c) { C d = c; }
> 
> foo() has no idea if c is ref counted or gc. Therefore, it has to check 
> every time, at run time. All the machinery has to be there, just in case.
> 
>> If we are really still in the age, with vtables and alignment padding 
>> and god knows what else a compiler writer needs per object to 
>> correctly do his work, where another 4 bytes of int is considered 
>> prohibitory, then I give up the whole idea <g>.
> 
> It's not just another 4 bytes.

You'd have to outlaw:
T a;
scope(T) b = a;

You'd also have to outlaw:
scope(T) a;
T b = a;

This would be more obvious with a wrapper struct than a storage class.