On Monday, 1 May 2017 at 19:02:11 UTC, H. S. Teoh wrote:
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?
Initially when designing the DIP I haven't thought about this
use-case, but I've had more thought put into it recently.
Unfortunately it came a bit late, but I thought about an
alternate DIP design to this one, where instead of inheriting
*all* base class ctors, the user would selectively inherit
*specific* ctors. The alternate proposal is just a PR for now:
https://github.com/dlang/DIPs/pull/60 (direct link
https://github.com/AndrejMitrovic/DIPs/blob/d4ae8866d52f1a17a5c4ff9f2c843d61dad5e7e7/DIPs/DIP1004-alternative.md)
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)?
Very good question, especially about future-proofing. This goes
back to my response to #1, and makes me think that in fact the
alternate design in https://github.com/dlang/DIPs/pull/60 is
probably a better idea.
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?
It would have to be illegal.
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; }
?
There shouldn't be any semantic difference.
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)?
I'm not really sure of real-world examples where this would be
the case, where a class designer has explicitly derived from a
class but failed to write any constructors *and* intends for that
class not to be constructible. In such a case, surely the
designer of the class would label the class as `abstract`.
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.)
I feel like implicit constructor inheritance where there are no
new additional constructors being introduced in the derived class
would be a safe default to have. I can't imagine a case where
this would cause bugs in user code. But I'm open to seeing such
examples, of course.
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?
Not unless the two classes were part of the same module (and thus
had symbol visibility). However the implicitly inherited
constructor would also be private in the derived class as well,
so that should answer the second part of that question.
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.)
Interesting idea. That would be another point for the alternate
proposal in
https://github.com/AndrejMitrovic/DIPs/blob/d4ae8866d52f1a17a5c4ff9f2c843d61dad5e7e7/DIPs/DIP1004-alternative.md, which would allow code such as:
class A { protected this ( int x ) { } }
class B { public alias super.this(int) this; }
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?
It's hard to tell whether it would cause problems, although it is
indeed possible to accidentally inherit a ctor even if it's
unwanted.
I see the general sentiment, and I think the big question to be
asked here is: do we want a way to inherit "everything at once",
or have a simple syntax to selectively inherit some constructors
as in
https://github.com/AndrejMitrovic/DIPs/blob/d4ae8866d52f1a17a5c4ff9f2c843d61dad5e7e7/DIPs/DIP1004-alternative.md.
