DIP 1004 Preliminary Review Round 1

[Andrej Mitrovic via Digitalmars-d]

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.