www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - template error instantiating

reply "ref2401" <refactor24 gmail.com> writes:
I get "template instance main.MyClass!(int) error instantiating" 
in the following case:

public class MyClass(TStuff)
{
	public void foo(TStuff item)
	{}

	public void foo(TRange)(TRange items)
	if (isInputRange!TRange && is(ElementType!TRange == TStuff))
	{}
}

void main(string[] argv)
{
	MyClass!int instance = new MyClass!int();

	return;
}

but if i rename one of the "foo" overloads then code will be 
compiled.
Nov 17 2012
next sibling parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Saturday, 17 November 2012 at 18:28:10 UTC, ref2401 wrote:
 I get "template instance main.MyClass!(int) error 
 instantiating" in the following case:

 public class MyClass(TStuff)
 {
 	public void foo(TStuff item)
 	{}

 	public void foo(TRange)(TRange items)
 	if (isInputRange!TRange && is(ElementType!TRange == TStuff))
 	{}
 }

 void main(string[] argv)
 {
 	MyClass!int instance = new MyClass!int();

 	return;
 }

 but if i rename one of the "foo" overloads then code will be 
 compiled.

Full error message is: Error: template main.MyClass!(int).MyClass.foo(TRange) if (isInputRange!(TRange) && is(ElementType!(TRange) == TStuff)) conflicts with function main.MyClass!(int).MyClass.foo at main.d(3) main.d(13): Error: template instance main.MyClass!(int) error instantiating That's why renaming foo makes dmd happy. Alternatively you can add extra dummy parenthesis in the first foo to make it template function. This is not the first case I see adding parenthesis to function declarations solves compilation errors.
Nov 17 2012
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Maxim Fomin wrote:

 solves compilation errors

From the docs: | If a template has exactly one member in it, and the name of | that member is the same as the template name, that member | is assumed to be referred to in a template instantiation It seems that the problem is located in this definition. -manfred
Nov 17 2012
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Maxim Fomin wrote:

 related to the issue?

... I can see that the definition is ambiguous. And if the coder didnt't realize the ambiguousness as you do ... -manfred
Nov 17 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 11/18/2012 12:14 AM, Manfred Nowak wrote:
 Maxim Fomin wrote:

 related to the issue?

... I can see that the definition is ambiguous. And if the coder didnt't realize the ambiguousness as you do ... -manfred

The code given in the original post is valid D code.
Nov 17 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/18/2012 09:19 AM, Maxim Fomin wrote:
 On Saturday, 17 November 2012 at 23:28:21 UTC, Timon Gehr wrote:
 On 11/18/2012 12:14 AM, Manfred Nowak wrote:
 Maxim Fomin wrote:

 related to the issue?

... I can see that the definition is ambiguous. And if the coder didnt't realize the ambiguousness as you do ... -manfred

The code given in the original post is valid D code.

This is a poor argument. Validness of code is determined by the spec (and I have not found anything related to the issue)

TDPL is very explicit about this.
 and is supported by
 presence of alternative compilers so you can switch to another if you
 have problems with one of them.

 This is not the case of D. Unfortunately D spec is incomplete and does
 not give answers even for not tricky questions. Also, only few commits
 to dmd which affect language have corresponding pulls to dlang.org. And
 presence of alternative compilers does not help in majority cases
 because they share same frontend as well as bugs in it. This makes D's
 bugs to be a chief if you cannot fallback to ldc or gdc and makes
 theoretical validness of code irrelevant at practice.

It is very relevant if the goal is to improve the situation.
Nov 18 2012
prev sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Maxim Fomin wrote:

 How this is related

to have ambiguities and I believe that the ambiguity I see escapes the intended scope; but I am not willing to check for this---and it is fruitless to explain such cases. -manfred
Nov 18 2012
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Saturday, 17 November 2012 at 20:44:05 UTC, Manfred Nowak 
wrote:
 Maxim Fomin wrote:

 solves compilation errors

From the docs: | If a template has exactly one member in it, and the name of | that member is the same as the template name, that member | is assumed to be referred to in a template instantiation It seems that the problem is located in this definition. -manfred

How eponymous templates are related to the issue?
Nov 17 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Saturday, 17 November 2012 at 18:28:10 UTC, ref2401 wrote:
 I get "template instance main.MyClass!(int) error 
 instantiating" in the following case:

 public class MyClass(TStuff)
 {
 	public void foo(TStuff item)
 	{}

 	public void foo(TRange)(TRange items)
 	if (isInputRange!TRange && is(ElementType!TRange == TStuff))
 	{}
 }

 void main(string[] argv)
 {
 	MyClass!int instance = new MyClass!int();

 	return;
 }

 but if i rename one of the "foo" overloads then code will be 
 compiled.

Template functions are currently not overloadable with non-template ones. As a workaround (if foo(TStuff) doesn't need to be virtual), you can turn it into a template function (without parameters, i.e. foo()(TStuff item)) as well. David
Nov 17 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/17/2012 07:28 PM, ref2401 wrote:
 I get "template instance main.MyClass!(int) error instantiating" in the
 following case:

 public class MyClass(TStuff)
 {
      public void foo(TStuff item)
      {}

      public void foo(TRange)(TRange items)
      if (isInputRange!TRange && is(ElementType!TRange == TStuff))
      {}
 }

 void main(string[] argv)
 {
      MyClass!int instance = new MyClass!int();

      return;
 }

 but if i rename one of the "foo" overloads then code will be compiled.

Making the first overload a template fixes your issue, but note that your code is indeed valid D code. It is the compiler which does not implement overloading of functions vs. function templates yet.
Nov 17 2012
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Saturday, 17 November 2012 at 23:14:56 UTC, Manfred Nowak 
wrote:
 Maxim Fomin wrote:

 related to the issue?

... I can see that the definition is ambiguous. And if the coder didnt't realize the ambiguousness as you do ... -manfred

There is compilation error when instantiating class template which has on overload set consisting of template and non-template function. How this is related to eponymous templates?
Nov 17 2012
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Saturday, 17 November 2012 at 23:28:21 UTC, Timon Gehr wrote:
 On 11/18/2012 12:14 AM, Manfred Nowak wrote:
 Maxim Fomin wrote:

 related to the issue?

... I can see that the definition is ambiguous. And if the coder didnt't realize the ambiguousness as you do ... -manfred

The code given in the original post is valid D code.

This is a poor argument. Validness of code is determined by the spec (and I have not found anything related to the issue) and is supported by presence of alternative compilers so you can switch to another if you have problems with one of them. This is not the case of D. Unfortunately D spec is incomplete and does not give answers even for not tricky questions. Also, only few commits to dmd which affect language have corresponding pulls to dlang.org. And presence of alternative compilers does not help in majority cases because they share same frontend as well as bugs in it. This makes D's bugs to be a chief if you cannot fallback to ldc or gdc and makes theoretical validness of code irrelevant at practice.
Nov 18 2012
prev sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 18 November 2012 at 10:19:47 UTC, Manfred Nowak wrote:
 I will be quiet on this, because non formal specifications tend
 to have ambiguities and I believe that the ambiguity I see
 escapes the intended scope; but I am not willing to check for
 this---and it is fruitless to explain such cases.

I'm pretty sure it is not related at all, you might have just been mistaking it for something else. However, if you really think it is unclear, please don't just ignore that, but submit an issue or preferably a d-p-l.org pull request so that the ambiguity will be removed. David
Nov 18 2012