Thread overview
Overloading template functions
Jul 30, 2005
Sean Kelly
Jul 30, 2005
Manfred Nowak
Jul 30, 2005
Sean Kelly
Jul 30, 2005
Sean Kelly
Jul 31, 2005
Sean Kelly
July 30, 2005
I should have expected this, but it took me a bit by surprise:

# template fn(T)
# {
#     void fn( T val )
#     {
#
#     }
# }
#
# template fn(T)
# {
#     void fn( T val1, T val2 )
#     {
#
#     }
# }
#
# void main()
# {
#     fn!(int)( 1 );
# }

Compiling gives the error:

test.d(10): template test.fn(T) conflicts with test.fn(T) at test.d(1)

I can get around this by moving both functions into the same template block and calling the function as fn!(int).fn(1) but this is a bit unwieldy.  I would love it if we had some sort of abbreviated template function syntax that allowed them to be overloaded properly and called via the compact form.


Sean


July 30, 2005
Sean Kelly <sean@f4.ca> wrote:

[...]
> I would love it if we had some sort of
> abbreviated template function syntax that allowed them to be
> overloaded properly and called via the compact form.

In essence you want to be allowed to split the contents of currently only one allowed template body into several body fragments.

Surely the compiler can be adviced to recombine this fragments to only onje template body.

But what rules should the compiler follow by this recombination and what other possible extensions will conflict with such fragmentation?

-manfred
July 30, 2005
In article <dcfei8$bvh$1@digitaldaemon.com>, Manfred Nowak says...
>
>Sean Kelly <sean@f4.ca> wrote:
>
>[...]
>> I would love it if we had some sort of
>> abbreviated template function syntax that allowed them to be
>> overloaded properly and called via the compact form.
>
>In essence you want to be allowed to split the contents of currently only one allowed template body into several body fragments.
>
>Surely the compiler can be adviced to recombine this fragments to only onje template body.
>
>But what rules should the compiler follow by this recombination and what other possible extensions will conflict with such fragmentation?

Thing is, the compiler already doesn't complain that I have two template functions with the same name and parameter scope (ie. two of 'template fn(T)'). In practice it seems like it just instantiates the first applicable one rather than checking further.  What I would like it to do is evaluate all applicable templates in lookup scope.  If it is a function call then the contents could be considered for overload resolution.  If it is something else then the compiler should likely display an error about multiply defined symbols.

While we're on the topic, I would also like it if template contents were only instantiated as needed.  ie.

# class C(T) {
#     void fn1() {}
#     void fn2() { static assert( false ); }
# }
# void main() {
#     C!(int) c = new C!();
#     c.fn1();
# }

In C++, the above compiles and runs just fine--fn2 is never instantiated because it is never called.  In D, the entire template contents are instantiated and this will fail on the static assert during compilation.

Basically, I want the behavior of C++ templates but the flexibility of D templates.  I realize that this may require template handling to be a bit more complex than Walter would like, but it never hurts to ask :)


Sean


July 30, 2005
In article <dcg9l0$113i$1@digitaldaemon.com>, Sean Kelly says...
>
>While we're on the topic, I would also like it if template contents were only instantiated as needed.  ie.
>
># class C(T) {
>#     void fn1() {}
>#     void fn2() { static assert( false ); }
># }
># void main() {
>#     C!(int) c = new C!();
>#     c.fn1();
># }
>
>In C++, the above compiles and runs just fine--fn2 is never instantiated because it is never called.  In D, the entire template contents are instantiated and this will fail on the static assert during compilation.

I'm going to take this back.  I like being able to do things like this in D:

# class C(T) {
#     static assert(is(T:int));
# }

and runs somewhat contrary to what I asked for above.  Unless this rule could only apply to member functions, which seems a bit arbitrary.


Sean


July 31, 2005
In article <dcetge$2t8f$1@digitaldaemon.com>, Sean Kelly says...
>
>I should have expected this, but it took me a bit by surprise:
>
># template fn(T)
># {
>#     void fn( T val )
>#     {
>#
>#     }
># }
>#
># template fn(T)
># {
>#     void fn( T val1, T val2 )
>#     {
>#
>#     }
># }
>#
># void main()
># {
>#     fn!(int)( 1 );
># }
>
>Compiling gives the error:
>
>test.d(10): template test.fn(T) conflicts with test.fn(T) at test.d(1)

Oops.  In paring down my test case the error changed.  The original one complained that I'd passed the wrong number of arguments to fn().  I'm trying to reproduce the problem again now.


Sean