www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Can not override template and nontemplate function

reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
D can not override template and nontemplate function:

void foo(bool param)
{
	if(param)
	{
		//do something useful
	}
	else
	{
		//do something else
	}
}

void foo(bool param)()
{
	static if(param)
	{
		//do something useful
	}
	else
	{
		//do something else
	}
}

void main()
{
}

dmd output:
src/main.d(13): Error: template main.foo(bool param)() conflicts 
with function main.foo at src/main.d(1)

Does exist any reason to deny this, or it's just compiler bug?
I think that compiler can always understand what I want:

//nontemplate function call
foo(true);
//template function call
foo!true();
Aug 31 2013
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 8/31/13, ilya-stromberg <ilya-stromberg-2009 yandex.ru> wrote:
 D can not override template and nontemplate function.

It was a long-standing bug which was fixed in git-head and will work in the 2.064 release.
Aug 31 2013
parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 31.08.2013 12:53, schrieb Andrej Mitrovic:
 On 8/31/13, ilya-stromberg <ilya-stromberg-2009 yandex.ru> wrote:
 D can not override template and nontemplate function.

It was a long-standing bug which was fixed in git-head and will work in the 2.064 release.

Also, for completeness, it's possible to work around it for now using a parameter-less template: void foo()(bool param) { // ... } void foo(bool param)() { // ... }
Aug 31 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-08-31 14:19, monarch_dodra wrote:

 While we are at it, this is also the way to "force" attribute inference
 on a function.

And force a function to appear with its implementation in interface files. Useful for CTFE. -- /Jacob Carlborg
Aug 31 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/31/2013 06:39 PM, monarch_dodra wrote:
 Although arguably, since foo is already in a parameterized context,
 *ideally* it should already be infered (but that is not the case today).

http://d.puremagic.com/issues/show_bug.cgi?id=7511
Aug 31 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Saturday, 31 August 2013 at 11:22:17 UTC, Sönke Ludwig wrote:
 Also, for completeness, it's possible to work around it for now 
 using a parameter-less template:

 void foo()(bool param)
 {
   // ...
 }
 void foo(bool param)()
 {
   // ...
 }

While we are at it, this is also the way to "force" attribute inference on a function.
Aug 31 2013
prev sibling next sibling parent "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
On Saturday, 31 August 2013 at 12:19:17 UTC, monarch_dodra wrote:
 While we are at it, this is also the way to "force" attribute 
 inference on a function.

Can you print any code example, please?
Aug 31 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Saturday, 31 August 2013 at 12:53:17 UTC, ilya-stromberg wrote:
 On Saturday, 31 August 2013 at 12:19:17 UTC, monarch_dodra 
 wrote:
 While we are at it, this is also the way to "force" attribute 
 inference on a function.

Can you print any code example, please?

AFAIK template function attributes are always inferred. So converting normal function to parameter-less template function forces it.
Aug 31 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Saturday, 31 August 2013 at 12:53:17 UTC, ilya-stromberg wrote:
 On Saturday, 31 August 2013 at 12:19:17 UTC, monarch_dodra 
 wrote:
 While we are at it, this is also the way to "force" attribute 
 inference on a function.

Can you print any code example, please?

//This function is system, not pure, and throws. void foo() {} //This function is safe, pure and nothrow. void bar()() It's a trick that is useful when doing non-template functions inside a templated struct. EG: struct S(T) { T t; T foo() { return t; } } Here, we don't know if foo is nothrow, as the postblit could throw, for example. If we make it a template, then the compiler deduces it for us. Although arguably, since foo is already in a parameterized context, *ideally* it should already be infered (but that is not the case today).
Aug 31 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Saturday, 31 August 2013 at 16:39:22 UTC, monarch_dodra wrote:
 It's a trick that is useful when doing non-template functions 
 inside a templated struct. EG:

 struct S(T)
 {
     T t;
     T foo()
     {
         return t;
     }
 }

 Here, we don't know if foo is nothrow, as the postblit could 
 throw, for example. If we make it a template, then the compiler 
 deduces it for us.

Bad example, the "correct" example is one that uses voldermort typing: auto foo(T)() { struct S //S is not a template { void bar(){} } return S(); } void main() pure nothrow system { auto s = foo!int(); s.bar(); //Error here! } but, again, arguably, that should have "just worked" (tm)
Aug 31 2013
prev sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Saturday, 31 August 2013 at 18:47:02 UTC, Timon Gehr wrote:
 On 08/31/2013 06:39 PM, monarch_dodra wrote:
 Although arguably, since foo is already in a parameterized 
 context,
 *ideally* it should already be infered (but that is not the 
 case today).

http://d.puremagic.com/issues/show_bug.cgi?id=7511

This is the "first" example. It doesn't work for the second. It doesn't go deep enough (non-template function in a non-template struct declared in a template-function). Basically voldermorts. Real life example: //---- import std.range; void main() pure { chain([1], [2]); //not pure. } //----
Aug 31 2013