Newbie initial comments on D language - scope

[Edward Diener]

Michel Fortin wrote:
> On 2008-02-03 08:20:32 -0500, Edward Diener 
> <eddielee_no_spam_here at tropicsoft.com> said:
> 
>> I am fully cognizant of a dynamically typed language since I program 
>> in Python also. I agree there is no fixed dividing line. But the 
>> difference between static typing and dynamic typing is well defined in 
>> a statically typed language like D. My argument was that for 'scope' 
>> to be really effective it needs to consider the dynamic type at 
>> run-time and not just the static type as it exist at compile time.
> 
> Considering the dynamic type at runtime means you need to check if 
> you're dealing with a reference-counted object each time you copy a 
> reference to that object to see if it the reference count needs 
> adjusting. This is significant overhead over the "just copy the pointer" 
> thing you can do in a GC. Basically, just checking this will increase by 
> two or three times the time it take to copy an object reference... I can 
> see why Walter doesn't want that.

I am not knowledgable about the actual low-level difference between the 
compiler statically checking the type of an object or dynamically 
checking the type of an object, and the run-time costs involved.

Yet clearly D already has to implement code when scopes come to an end 
in order to destroy stack-based objects, since structs ( user-define 
value types ) are already supported and can have destructors. So the 
added overhead goes from having to identify structs which must have 
their destructor called at the end of each scope to having to also 
identify 'scope' objects which must have their reference count 
decremented at the end of each scope and have their destructor called if 
the reference count reaches 0. The only difference I see, aside from the 
  run-time time overhead, is the actual identification for a greater set 
of objects.

> 
> Beside, the overhead of actually checking the type of the class will be 
> approximativly the same as doing the reference counting. Given this, 
> it's much better to always just do the reference counting than checking 
> dynamically if it's needed.
> 
> 
>> class C { ... }
>> scope class D : C { ... }
>>
>> [...]
>>
>> This may make things much easier for the compiler, but it requires the 
>> end user knowledge of 'scope', which has been specified at the class 
>> level, to be applied at the syntax level. Intuitively I feel the 
>> compiler can figure this out, and that 'scope' should largely be 
>> totally transparent to the end user above at the syntax level.
> 
> Well, if the compiler is to be able to distinguish scope at compile 
> time, then it needs a scope flag (either explicit or implicit) on each 
> variable. This is exactly what Walter has proposed to do. He prefers the 
> explicit route because going implicit isn't going to work in too many 
> cases. For instance, let's have a function that returns a C:
> 
>     C makeOne() {
>         if (/* random stuff here */)
>             return new C;
>         else
>             return new D;
>     }
> 
> Now let's call the function:
> 
>     C c = makeOne();
> 
> How can you know at compile time if the returned object of that function 
> call is scoped or not? You can't, and therfore the compiler would need 
> to add code to check if the returned object is scope or not, with a 
> significant overhead, each time you assign a C.
> 
> If however you make scope known at compile time:
> 
>     scope C makeOne() {
>         if (/* random stuff here */)
>             return new C;
>         else
>             return new D;
>     }
> 
>     scope C c = makeOne();
> 
> Now the compiler knows it must generate reference counting code for the 
> following assignment, and any subsequent assignment of this type, and it 
> won't have to generate code to dynamically everywhere you use a C check 
> the "scopeness".

Would you agree that all you are doing here is specifically telling the 
compiler that an object is 'scope' when it is created rather than having 
the compiler figure it out for itself by querying the dynamic type of 
the object at creation time ?

If you do, then a much simpler, and to the point, example would be based 
on my initial OP:

scope class C { ... }

scope C c = new C(...);

I specified that the scope keyword for creating the object is redundant. 
The compiler can figure it out. The major difference in opinion is that 
I think the compiler should figure it out from the dynamic type of the 
object at run-time and not from the static type of the object.

If Walter decides that creating code which at run-time determines the 
dynamic type of an object in order to implement RAII in D is too much 
overhead, I will understand. But I do no think it will be a solution for 
RAII in GC in my own understanding of what this should entail.