On Monday, 1 May 2017 at 16:08:36 UTC, Andrej Mitrovic 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.

Then i have nothing to say and you can count me as a supporter of this DIP. As a personal matter i don't even care about the problem that's to have the ability to select a restricted set among the __ctors of the base.

About protection attributes i think that the rules applied to OOP should be followed. Private __ctors can only be inherited in derived if derived is in the same module, otherwise not. Protected and public __ctors can always be inherited. Package __ctors can be inherited in the same package.

Note that i always wondered why in the first place constructors and destructors were not designed to be virtual functions, like in other languages...

On Tuesday, 2 May 2017 at 09:03:27 UTC, deadalnix wrote:
> 100% in favor of the constructor behavior change in case no constructor is in the derived class.

I think we could even split this up into two separate proposals, because this part of the DIP is fairly non-controversial and could be approved much faster (and implementation-wise it should be fairly simple to support).

On Tuesday, 2 May 2017 at 09:03:27 UTC, deadalnix wrote:
> 100% in favor of the constructor behavior change in case no constructor is in the derived class.

I agree.

On Tuesday, 2 May 2017 at 18:02:15 UTC, Adam D. Ruppe wrote:
> On Tuesday, 2 May 2017 at 09:03:27 UTC, deadalnix wrote:
>> 100% in favor of the constructor behavior change in case no constructor is in the derived class.
>
> I agree.

So do I.

However I oppose the other part of the DIP since it's already possible today.

class FileException : Exception
{
    this(ErrorCode error_code, string file = __FILE__, uint line = __LINE__ )
    {
        super("FileNotFound", file, line);
    }

    alias __ctor = super.__ctor;
}

On Wednesday, 3 May 2017 at 09:13:54 UTC, Daniel N wrote:
> However I oppose the other part of the DIP since it's already possible today.
>
> class FileException : Exception
> {
>     this(ErrorCode error_code, string file = __FILE__, uint line = __LINE__ )
>     {
>         super("FileNotFound", file, line);
>     }
>
>     alias __ctor = super.__ctor;
> }

I was excited for a second, but that doesn't actually compile.

Error: alias test.FileException.__ctor is not a constructor; identifiers starting with __ are reserved for the implementation

On Wednesday, 3 May 2017 at 12:46:19 UTC, Andrej Mitrovic wrote:
> On Wednesday, 3 May 2017 at 09:13:54 UTC, Daniel N wrote:
>> However I oppose the other part of the DIP since it's already possible today.
>>
>> class FileException : Exception
>> {
>>     this(ErrorCode error_code, string file = __FILE__, uint line = __LINE__ )
>>     {
>>         super("FileNotFound", file, line);
>>     }
>>
>>     alias __ctor = super.__ctor;
>> }
>
> I was excited for a second, but that doesn't actually compile.
>
> Error: alias test.FileException.__ctor is not a constructor; identifiers starting with __ are reserved for the implementation

I used this technique many times with many different compiler versions...

The trick is that your child class need to have defined at least 1 constructor before the alias.

This should work:
this() {}
alias __ctor = super.__ctor;

This will give the error message you saw:
alias __ctor = super.__ctor;
this() {}

On Wednesday, 3 May 2017 at 12:58:17 UTC, Daniel N wrote:
> The trick is that your child class need to have defined at least 1 constructor before the alias.
>
> This should work:
> this() {}
> alias __ctor = super.__ctor;
>
> This will give the error message you saw:
> alias __ctor = super.__ctor;
> this() {}

I see. It does look like an accidental feature (as in, that it could break in the future).

On 05/03/2017 05:09 PM, Andrej Mitrovic wrote:
> On Wednesday, 3 May 2017 at 12:58:17 UTC, Daniel N wrote:
>> The trick is that your child class need to have defined at least 1 constructor before the alias.
>>
>> This should work:
>> this() {}
>> alias __ctor = super.__ctor;
>>
>> This will give the error message you saw:
>> alias __ctor = super.__ctor;
>> this() {}
> 
> I see. It does look like an accidental feature (as in, that it could break in the future).

You could switch to:

```
this(A...)(auto ref A a)
{
	import std.functional;
	super(forward!a);
}
```

but that doesn't work with all the parameter storage classes.
lazy is no longer lazy for example.

-- 
Mike Wey

On Wednesday, 3 May 2017 at 15:09:03 UTC, Andrej Mitrovic wrote:
> On Wednesday, 3 May 2017 at 12:58:17 UTC, Daniel N wrote:
>> The trick is that your child class need to have defined at least 1 constructor before the alias.
>>
>> This should work:
>> this() {}
>> alias __ctor = super.__ctor;
>>
>> This will give the error message you saw:
>> alias __ctor = super.__ctor;
>> this() {}
>
> I see. It does look like an accidental feature (as in, that it could break in the future).

Well, I was thinking one could put it in a mixin, then it would be officially supported and user-facing code wouldn't have to use __symbols. One benefit with using __ctor is that the syntax doesn't clash with future "alias this" improvements.

On Tuesday, 2 May 2017 at 11:13:35 UTC, Andrej Mitrovic wrote:
> On Tuesday, 2 May 2017 at 09:03:27 UTC, deadalnix wrote:
>> 100% in favor of the constructor behavior change in case no constructor is in the derived class.
>
> I think we could even split this up into two separate proposals, because this part of the DIP is fairly non-controversial and could be approved much faster (and implementation-wise it should be fairly simple to support).

<3