Hello everybody,

Could someone explain why D do not lookup for appropriate super
constructor? It is in specs:
> If there is no constructor for a class, but there is a constructor  for the base class, a default constructor of the form:
> this() { }
But i do not understand intension. Is it so hard for compiler to find
suitable constructor in base class(es)?

simple example:
> class Foo
> {
>   this(char[] name) { }
> }
> 
> class FooBar : Foo
> {
>   /* no ctors defined */
> }

Calling `auto o = new FooBar("test")` result to "constructor FooBar.this
no match for implicit super() call in constructor" message.

Thanks.
-- 
serg.

Serg Kovrov wrote:
> Hello everybody,
> 
> Could someone explain why D do not lookup for appropriate super
> constructor? It is in specs:
>> If there is no constructor for a class, but there is a constructor  for the base class, a default constructor of the form:
>> this() { }
> But i do not understand intension. Is it so hard for compiler to find
> suitable constructor in base class(es)?

I suspect this is because a default ctor is generated for classes with no ctor defined, and the lookup rules in D then keep the compiler from looking in base classes for a match since the current class has a ctor defined.


Sean

"Serg Kovrov" <kovrov@no.spam> wrote in message news:ebn850$3qa$1@digitaldaemon.com...
> Hello everybody,
>
> Could someone explain why D do not lookup for appropriate super constructor? It is in specs:
>> If there is no constructor for a class, but there is a constructor  for
>> the base class, a default constructor of the form:
>> this() { }

That really should read "this() { super(); }".

> But i do not understand intension. Is it so hard for compiler to find suitable constructor in base class(es)?

It's not really trivial.  Basically the rule would have to change so that if a class were defined without any ctors, it would have to create a ctor for each ctor that the base class has, and forward the parameters.  So your code would insert an implicit "this(char[] name) {super(name);}" in FooBar.  That seems like a little too much automation for very rarely any real benefit. Most of the time you're going to be making new constructors for the derived class anyway, so it's kind of a niche problem.

Jarrett Billingsley wrote:
> "Serg Kovrov" <kovrov@no.spam> wrote in message 
>> But i do not understand intension. Is it so hard for compiler to find
>> suitable constructor in base class(es)?
> 
> It's not really trivial.  Basically the rule would have to change so that if a class were defined without any ctors, it would have to create a ctor for each ctor that the base class has, and forward the parameters.  So your code would insert an implicit "this(char[] name) {super(name);}" in FooBar.  That seems like a little too much automation for very rarely any real benefit. Most of the time you're going to be making new constructors for the derived class anyway, so it's kind of a niche problem. 

Personally I do not see it as too much automation, but a little bit source code overhead. I believe Walter cares about unnecessary typing overhead.

-- 
serg.

The major problem I see with this is say you have:

class Foo
{
	this(){...}
	this(char){...}
	this(char[]){...}
	... // 27 more constructors
}

class Bar : Foo
{
	// all constructors implicit
}

Now add one constructor to Bar.
All of the implicit constructors vanish. Have fun tracking that all down.

Implicit constructors violate the idea that "simple changes should be simple" (my position).

a Better solution might be to allow:

class Bar:Foo
{
	alias super(char[]);
	 // shorthand for: this(char[] arg){super(arg)};
}

Jarrett Billingsley wrote:
> "Serg Kovrov" <kovrov@no.spam> wrote in message news:ebn850$3qa$1@digitaldaemon.com...
> 
>>Hello everybody,
>>
>>Could someone explain why D do not lookup for appropriate super
>>constructor? It is in specs:
>>
>>>If there is no constructor for a class, but there is a constructor  for the base class, a default constructor of the form:
>>>this() { }
> 
> 
> That really should read "this() { super(); }".
> 
> 
>>But i do not understand intension. Is it so hard for compiler to find
>>suitable constructor in base class(es)?
> 
> 
> It's not really trivial.  Basically the rule would have to change so that if a class were defined without any ctors, it would have to create a ctor for each ctor that the base class has, and forward the parameters.  So your code would insert an implicit "this(char[] name) {super(name);}" in FooBar.  That seems like a little too much automation for very rarely any real benefit. Most of the time you're going to be making new constructors for the derived class anyway, so it's kind of a niche problem. 
> 
> 

BCS wrote:
> The major problem I see with this is say you have:
> 
> class Foo
> {
>     this(){...}
>     this(char){...}
>     this(char[]){...}
>     ... // 27 more constructors
> }
> 
> class Bar : Foo
> {
>     // all constructors implicit
> }
> 
> Now add one constructor to Bar.
> All of the implicit constructors vanish. Have fun tracking that all down.
> 
> Implicit constructors violate the idea that "simple changes should be simple" (my position).
> 
> a Better solution might be to allow:
> 
> class Bar:Foo
> {
>     alias super(char[]);
>      // shorthand for: this(char[] arg){super(arg)};
> }

Currently there is no implicit super constructors calls at all, thats the problem. Explicitly defining aliases (just like duplication of dumb ctors calling supers) is not a solution. Because if base class changed signatures for its constructors or add new one, you must fix *all* class hierarchy. And compiler not allays will give you a hint. If hierarchy is big enough chances very high that you miss something.

PS. moved from digitalmars.D.learn to digitalmars.D
-- 
serg.