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.
All classes are dynamic types
I do not see it anywhere in the dlang specification that
supports your claim.
https://dlang.org/spec/class.html
This is the reason why all D classes have a vtable attached (with
attached runtime type info). *All* class-specific features are
centered around this - casts use rtti, inheritance and interfaces
use the vtable. It is the reason why D classes are reference
types - otherwise, when you substitute it, you'd risk slicing the
object.
If you took the dynamic aspect out of classes, you'd have an
entirely different animal... the thing D calls a "struct".
Why can't it produce a warning message regarding implied
classes conversion if it detects mismatch attributes?
The entire purpose of OOP inheritance existing is the
substitution principle, that subclasses can take the place of
base classes transparently. This is an either-or situation: if we
want to keep the current definition of classes, bug 17592 MUST be
closed as "wontfix" as it is by design to maintain
substitutiability.
If we want to fix #17592, we MUST redefine the language's
definition of class destructors to follow inheritance-style rules
on matching attribute (even if they are actually implemented as a
chain), again to guarantee substitutability is not broken.
There's no middle ground possible.
