On Mon, May 01, 2017 at 02:55:28PM +0000, Mike Parker via Digitalmars-d wrote:
> DIP 1004 is titled "Inherited Constructors.
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1004.md
[...]
I'm appalled that the only discussion that has come up so far is related
to syntax rather than semantics. ;-)
Overall, I like this DIP. Reducing boilerplate is always a good thing
IMO, and is one of the things that attracted me to D in the first place.
That said, there are a few points I feel could be more thoroughly
explored:
1) Suppose my base class has 3 ctors, and I only want my derived class
to inherit 1 of them. Does this DIP allow for that?
2) If my derived class has no ctors (and the base class has a default
ctor but also several other ctors), what if I want to suppress
inheriting base class ctors (except the default)? Do I need to
individually list all base class ctors and attach @disable to them? How
would this interact with future-proofing my derived class in case the
base class changes in the future (e.g., more ctors got added)?
3) Is it legal to write `@disable this(int,int)` when the base class
doesn't have a matching ctor? This might happen, e.g., if the base
class ctor was removed after the fact. Or would all derived classes
that disabled the original ctor have to be updated?
4) If my derived class has no (explicit) ctors, is there any semantic
difference between writing:
class Derived : Base {}
vs.:
class Derived : Base { alias super.this this; }
? Would it be better to require the latter explicit form so that this
DIP is opt-in (and also prevents breaking existing code that uses
compile-time introspection)? Or would the added boilerplate (have to
write that alias line for all derived classes) make this DIP less
attractive? (Note that this essentially nullifies implicit ctor
inheritance, which is one of main points of this DIP. But the point is
that alternatives like this should be considered and argued against to
make this DIP stronger.)
5) How would this DIP interact with access controls? E.g., if the base
class has a private ctor, will that be inherited implicitly? Or if the
base class has a protected ctor, will the inherit ctor remain as
protected? Will there be a way to inherit a base class protected ctor
and make it public instead? (I.e., a form of forwarding, from a public
derived class ctor to a protected base class ctor.)
If the base class introduces new private ctors, will that cause any
problems with derived classes implicitly inheriting all ctors (assuming
they do inherit private ctors)?
At what point does it cross the line of requiring explicit declaration
of a forwarding ctor in the derived class?
T
--
Just because you can, doesn't mean you should.
