Newbie initial comments on D language - scope

Walter Bright newshound1 at digitalmars.com
Mon Feb 4 13:51:26 PST 2008


Edward Diener wrote:
> In your example justifying treating 'scope' as C++ treats 'const' the 
> 'const' is attached to the object upon instantiation of it.

Pedantically, it is not attached to the object. It is attached to the 
*type* of the object. The bits in the object do not change, and there is 
no way at runtime to examine the bits of the object to determine if it 
is const or not. The "const-ness" is purely a compile time attribute, 
i.e. it's part of the static type.


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

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.


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


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


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

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


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



More information about the Digitalmars-d mailing list