Newbie initial comments on D language - scope

[Edward Diener]

Walter Bright wrote:
> Edward Diener wrote:
>> My point is that 'scope' is attached to the type by the class 
>> designer. To me these are conceptually two different things. That is 
>> why I said that your example is a poor analogy. I should have made 
>> that clearer by my argument.
> 
> Whether the 'scope' is attached to the class definition or the variable 
> definition is a separate and orthogonal issue. As I understand it, our 
> difference is if an object can, at run time, be distinguished as being 
> scope or not, and should this be tested at runtime at each place where 
> assignment, copy construction, and scope exit happens.

Yes, this is important in support of 'scope' at run-time. For each 
object you would need to determine if it is 'scope' in the cases cited 
above and take the appropriate action if it is. The easiest way, 
although perhaps the slowest, is to find out if the dynamic type is a 
'scope' type at the junctures you mentioned. How you do that at the 
compiler level you best would know. One possibility that comes to mind, 
but perhaps erroneous because too simple, is to add a int reference 
count to every object and then set it to 1 whenever a 'scope' object ( 
an object specified as 'scope' or having a 'scope class type ) is 
created or when a reference to a 'scope' object is legally assigned to 
any object. This goes along with my feeling that you will need to keep 
track of 'scope' objects by attaching your mechanism to the object at 
run-time and not rely merely on something in the 'scope' class type, and 
that it is the dynamic type of the object and not the static type which 
matters.

> 
> I.e., should 'scope' be a part of the type of the object, or a dynamic 
> part of the runtime representation of an object? Both are technically 
> implementable.

My vote is the second. See above.

> 
> 
>> I was simply arguing against your assertion, using 'const' as an 
>> example, of not allowing a 'scope' object to be assigned to an object 
>> that is not 'scope'.
> 
> Ok.
> 
> 
>> Clearly in the polymorphic world of D, where a base class may not be 
>> 'scope' while a derived class may be 'scope', such a treatment can not 
>> be right, since the basis of polymorphism is to assign to a base class 
>> object a derived class reference.
> 
> Right. This is a reason why 'scope' for classes may need to be 
> eventually deprecated.

I think this is very wrong.

> 
> 
>> But I do not see why you think that every object must therefore have 
>> scope semantics.
> 
> 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.

> 
> 
>> You have already won that argument as I fully agree to what you say 
>> above. But I have no idea why you say that it is the crux of our 
>> disagreement. Care to elaborate ?
> 
> 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. 
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.

> 
>> No, I do not think that the scopeness of an object is best determined 
>> by the user and not the class designer. In fact I feel very strongly 
>> the opposite. The class designer knows whether his class has RAII or 
>> not and in the cast majority of cases the end user should not know or 
>> care.
> 
> This is a very interesting issue. I've been slowly coming to the 
> opposite conclusion that issues of where an object is created (and that 
> includes scope) should be the purvey of the object user. C++ and D have 
> class specific allocators, but that might be a mistake.

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.

> 
> 
>> My argument for scope injection is based purely on the practical 
>> considerations that there are types which can not possibly know if it 
>> is to be used with RAII or not. Template classes/structs which are 
>> containers are the most obvious as well as built-in arrays. That is 
>> why besides the ability for the class designer to specify 'scope' the 
>> end user should be able to do it at object creation time also.
> 
> 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.

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