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
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
parent reply "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
next sibling parent reply "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
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 parent reply "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
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 reply 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
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
prev 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