DIP 1004 is titled "Inherited Constructors.

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1004.md

All review-related feedback on and discussion of the DIP should occur in this thread. Due to DConf taking place during the review period, the period will be extended by a week. The review period will end at 11:59 PM ET on May 22 (3:59 AM GMT May 23), or when I make a post declaring it complete.

At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the formal review and evaluation by the language authors.

Thanks in advance to all who participate.

Destroy!

On Monday, 1 May 2017 at 14:55:28 UTC, Mike Parker wrote:
> DIP 1004 is titled "Inherited Constructors. [...]
> All review-related feedback on and discussion of the DIP should occur in this thread. [...]
> Destroy!

An obvious omission in the syntax variations [1]

- alias this() = super.this();

or

- alias this = super.this;


Why ?

1/ AliasDeclarationY [2] is the most modern and most used alias syntax nowadays.
2/ it's less confusing with the "alias this" that's used for static inheritance.

[1] https://github.com/dlang/DIPs/blob/master/DIPs/DIP1004.md#syntax-variations
[2] https://dlang.org/spec/declaration.html#AliasDeclarationY

On Monday, 1 May 2017 at 15:33:47 UTC, Basile B. wrote:
> On Monday, 1 May 2017 at 14:55:28 UTC, Mike Parker wrote:
>> DIP 1004 is titled "Inherited Constructors. [...]
>> All review-related feedback on and discussion of the DIP should occur in this thread. [...]
>> Destroy!
>
> An obvious omission in the syntax variations [1]
>
> - alias this() = super.this();
>
> or
>
> - alias this = super.this;
>

or even

    alias this() = Base.this()

with Base the identifier for the base class, which is already the syntax for virtual methods ;)

On Monday, 1 May 2017 at 15:33:47 UTC, Basile B. wrote:
> On Monday, 1 May 2017 at 14:55:28 UTC, Mike Parker wrote:
>> DIP 1004 is titled "Inherited Constructors. [...]
>> All review-related feedback on and discussion of the DIP should occur in this thread. [...]
>> Destroy!
>
> An obvious omission in the syntax variations [1]
>
> - alias this() = super.this();
>
> or
>
> - alias this = super.this;

I thought people would catch on that this is implied. :) The old-style or new-style alias syntax should both be allowed, in my opinion. The main issue is what to do about the parentheses, whether to include them or not.

On Mon, May 01, 2017 at 04:08:36PM +0000, Andrej Mitrovic via Digitalmars-d wrote:
> On Monday, 1 May 2017 at 15:33:47 UTC, Basile B. wrote:
> > On Monday, 1 May 2017 at 14:55:28 UTC, Mike Parker wrote:
> > > DIP 1004 is titled "Inherited Constructors. [...]
> > > All review-related feedback on and discussion of the DIP should
> > > occur in this thread. [...]
> > > Destroy!
> > 
> > An obvious omission in the syntax variations [1]
> > 
> > - alias this() = super.this();
> > 
> > or
> > 
> > - alias this = super.this;
> 
> I thought people would catch on that this is implied. :) The old-style or new-style alias syntax should both be allowed, in my opinion. The main issue is what to do about the parentheses, whether to include them or not.

I don't think new-style syntax is supported for `alias X this;`. I vaguely remember in the original discussions when new-style alias syntax was first introduced, that we decided against allowing `alias this = X;` because alias this held a special meaning that's different from the usual alias declaration, so the fact that they now have different syntaxes was seen as an advantage.


T

-- 
Тише едешь, дальше будешь.

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.

On Monday, 1 May 2017 at 18:34:43 UTC, H. S. Teoh wrote:
> so the fact that they now have different syntaxes was seen as an advantage.

Yeah, I remember that decision. I don't think I've ever agreed with it, though. :o)

We'll see.. I don't personally find it very important, I'm fine with either styles of syntax.

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.

On Monday, 1 May 2017 at 14:55:28 UTC, Mike Parker wrote:
> DIP 1004 is titled "Inherited Constructors.
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1004.md
>
> All review-related feedback on and discussion of the DIP should occur in this thread. Due to DConf taking place during the review period, the period will be extended by a week. The review period will end at 11:59 PM ET on May 22 (3:59 AM GMT May 23), or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the formal review and evaluation by the language authors.
>
> Thanks in advance to all who participate.
>
> Destroy!

100% in favor of the constructor behavior change in case no constructor is in the derived class.

Not convinced by the alias this trick. It doesn't pays for itself, IMO. It could be provided by a mixin or something and shouldn't be baked into the language.

On 5/2/17 11:03 AM, deadalnix wrote:
> On Monday, 1 May 2017 at 14:55:28 UTC, Mike Parker wrote:
>> DIP 1004 is titled "Inherited Constructors.
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1004.md
>>
>> All review-related feedback on and discussion of the DIP should occur
>> in this thread. Due to DConf taking place during the review period,
>> the period will be extended by a week. The review period will end at
>> 11:59 PM ET on May 22 (3:59 AM GMT May 23), or when I make a post
>> declaring it complete.
>>
>> At the end of Round 1, if further review is deemed necessary, the DIP
>> will be scheduled for another round. Otherwise, it will be queued for
>> the formal review and evaluation by the language authors.
>>
>> Thanks in advance to all who participate.
>>
>> Destroy!
>
> 100% in favor of the constructor behavior change in case no constructor
> is in the derived class.
>
> Not convinced by the alias this trick. It doesn't pays for itself, IMO.
> It could be provided by a mixin or something and shouldn't be baked into
> the language.

+1
Let's keep it simple.

---
Dmitry Olshansky