#dbugfix 17592

[Simen Kjærås]

On Thursday, 22 March 2018 at 14:48:04 UTC, 12345swordy wrote:
> On Thursday, 22 March 2018 at 02:35:41 UTC, Adam D. Ruppe wrote:
>> On Thursday, 22 March 2018 at 01:55:48 UTC, 12345swordy wrote:
>>> Are you suggesting that we need runtime version of 
>>> system/user attributes?
>>
>> We already have that in a sense - InvalidMemoryOperationError 
>> is thrown if you try to GC allocate from inside a GC 
>> destructor. The attributes are supposed to render such runtime 
>> errors impossible, catching them at compile time instead.
>>
> That is not a runtime version of system/user attributes! That 
> is custom checking for destructor! Hardly the same.

If I understand correctly, you envision a system where all or 
some GC operations would check the call stack to see if there are 
any @nogc functions there (the implementation might be different, 
but that would be my conceptual design). This seems like a 
possible design, but one that pessimizes the happy path to the 
detriment of everyone.


>> This is the reason why all D classes have a vtable attached 
>> (with attached runtime type info).
> C++ classes also have vtables which are typically implemented 
> as static arrays at compile time.
>
> Again I do not see it anywhere in the specification that 
> support your claim that all classes are dynamic. Otherwise if 
> what your saying is true then you should unable to use classes 
> in Better C mode, as that involves runtime.

Classes in D are dynamic in the same case that classes in C++, 
Java, C# or many other languages are dynamic - a reference to a 
base class might actually point to a derived class, and there's 
no way to know at compile-time what's actually hiding behind that 
reference. That's how it's been meant all through this thread, 
but it seems a misunderstanding has crept in.

In this case:

class A {}
class B : A {}

A var = new B();

var's *static* type is A. That's what typeof(var) will return, 
and it's the type the compiler knows about. It's the type for 
which we can look at the destructor at compile-time and say 'we 
cannot do this in a @nogc function'.

On the other side, var's *dynamic* type is B. If instead of 'new 
B()', there was an opaque function call, it's impossible to know 
the dynamic type until run-time, and there's not even a point 
where we can give the warning message you suggest.

--
   Simen