From issue 15744 test case:
template AddField(T) {
T b;
this(Args...)(T b, auto ref Args args)
{
this.b = b;
//this(args); // not OK (segfaults, issue 15744)
}
}
template construcotrs() {
int a;
this(int a) {
this.a = a;
}
}
struct Bar {
mixin construcotrs;
mixin AddField!(string);
}
void main() {
auto bar1 = Bar(5); // OK
auto bar2 = Bar("bar", 15); // also OK
}
In main, outside of construction functions, the Bar's overload set constructor (declared in AddField and constructors mixin template) called is accepted.
But from inside the constructor AddField.this(Args...)(T b, auto ref Args args), a constructor call this(args); cannot work.
it's merely inconsistent behavior, and should be treated as a rejects-valid bug.
Comment #1 by code — 2016-03-11T21:15:43Z
Why isn't this working? The lookup origin should already be Bar.
Note that you should still only be allowed to match a single member of an overload set.
Comment #2 by k.hara.pg — 2016-03-14T15:34:47Z
https://github.com/D-Programming-Language/dmd/pull/5524(In reply to Martin Nowak from comment #1)
> Why isn't this working? The lookup origin should already be Bar.
> Note that you should still only be allowed to match a single member of an
> overload set.
Because the call forms `super(...)` and `this(...)` are specially handled in CallExp.semantic(), and they didn't consider the case that the construcotor is OverloadSet.
Fix:
https://github.com/D-Programming-Language/dmd/pull/5524
Comment #3 by github-bugzilla — 2016-03-14T19:45:52Z