Template method and overloading

Ary Manzana ary at esperanto.org.ar
Wed May 30 15:27:30 PDT 2007


I've just tried it, it works.

---
module main;

import std.stdio;

template foo(T) {
	void foo(T x, int y) {
		writefln("In first with %s: %s", typeid(T), y);
	}
	void foo(T x, char[] y) {
		writefln("In second with %s: %s", typeid(T), y);
	}
}

void main() {
	int[] x;
	double[] y;
	
	foo!(int[]).foo(x, 1);
	foo!(double[]).foo(y, "hello");
}
---

Output:
In first with int[]: 1
In second with double[]: hello

The only problem is that you have to explicitly say which is T, because 
the "one member" rule dosen't apply anymore. Maybe the rule could be 
changed for functions, to allow this kind of overloads.

Is there any problem with this I'm not being able to see?

Ary Manzana escribió:
> I thought maybe the compiler could merge all the templates with the same 
> name and template parameters... I think this is ok as long as you don't 
> use mixins, because you'll end up mixing more stuff than what you really 
> want...
> 
> Unless... the merge is documented somewhere, and so there will be no 
> confusion at all. Most of the time you won't have two templated 
> functions and then would want to mix them, or have a templated function 
> and a raw template with the same name.
> 
> Is this possible?
> 
> Daniel Keep escribió:
>>
>> Ary Manzana wrote:
>>> Bill Baxter escribió:
>>>> Something like:
>>>>      public void Foo(T)(T p1)
>>>>      {
>>>>      }
>>>>
>>>>      public void Foo(T,dummy=float)(T p1, bool b)
>>>>      {
>>>>      }
>>>>
>>>> It's silly that you have to do that, but since that workaround is
>>>> available, I don't think Walter considers fixing it a very high 
>>>> priority.
>>> !
>>>
>>> This is so wrong. The language is trying to be elegant with "foreach",
>>> "delegate" and some other stuff, while there are holes in many other
>>> places, like this one.
>>>
>>> I'm not saying that it's bad the problem exists. I think it's bad fixing
>>> this kind of things has low priority, while adding new features to the
>>> language has high priority. I know fixing is boring, and new stuff is
>>> fun. But... Workaround Oriented Programming is not fun. :-(
>>
>> I'm pretty sure this hasn't been fixed not because it's boring, but
>> because it's hard.  As Jarret said, the original code expands to two
>> templates with exactly the same name and set of arguments.
>>
>> I mean, would you call it a bug that you can't have two methods with the
>> same name and same arguments, but differ by their contents?  This isn't
>> so much a bug with D, but just a limitation.
>>
>> I vaguely remember someone (possibly Walter) saying at some point that
>> fixing this would require changing the compiler to distinguish between
>> templates and templated functions; which would require duplicating a lot
>> of code, and making the front end a lot messier.  When there's a simple
>> (if ugly) workaround available, I don't see how this is more important
>> than getting good const semantics.
>>
>> This you can work around.  Working around a lack of good const is much
>> harder :)
>>
>>     -- Daniel
>>


More information about the Digitalmars-d-learn mailing list