www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Cannot overload member template functions

reply "Matthew Wilson" <admin.hat stlsoft.dot.org> writes:
        template detect(F) { final bool detect(F f)
        {
            . . .
        }}
        template detect(F) { final bool detect(F f, out value_type value)
        {
            . . .
        }}

I get "list.d(672): template detect(F) conflicts with List.detect(F) at
list.d(656)"

Is this according to the language, or a bug? If it's the lang, and it's
going to stay that way, I'll just go with different names.

(btw, of course thse are not according to the new naming convention that
we've been discussing, so this specific case may not happen.)
Jul 15 2004
parent reply "Matthew Wilson" <admin.hat stlsoft.dot.org> writes:
"Matthew Wilson" <admin.hat stlsoft.dot.org> wrote in message
news:cd7ss3$2sii$1 digitaldaemon.com...
         template detect(F) { final bool detect(F f)
         {
             . . .
         }}
         template detect(F) { final bool detect(F f, out value_type value)
         {
             . . .
         }}

 I get "list.d(672): template detect(F) conflicts with List.detect(F) at
 list.d(656)"

 Is this according to the language, or a bug? If it's the lang, and it's
 going to stay that way, I'll just go with different names.

Now I'm on an example that does seem like overloads should be allowed, min and max. value_type min() { . . . } template min(F) { final value_type min(F f) { . . . }} It seems to me that both of these are well named, and that to have different names for the two would be perverse, or at least inconsistent. So, may we have overloads of template member functions, please? :-))
Jul 15 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew Wilson" <admin.hat stlsoft.dot.org> wrote in message
news:cd7t8n$2sos$1 digitaldaemon.com...
 Now I'm on an example that does seem like overloads should be allowed, min
 and max.

         value_type min()
         {
             . . .
         }
         template min(F) { final value_type min(F f)
         {
             . . .
         }}

 It seems to me that both of these are well named, and that to have

 names for the two would be perverse, or at least inconsistent.

 So, may we have overloads of template member functions, please? :-))

Templates already overload based on partial specialization rules. They don't overload with non-templates, because that is a major source of complexity, confusion, and bugs in C++.
Jul 16 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cda94q$tb2$2 digitaldaemon.com...
 "Matthew Wilson" <admin.hat stlsoft.dot.org> wrote in message
 news:cd7t8n$2sos$1 digitaldaemon.com...
 Now I'm on an example that does seem like overloads should be allowed, min
 and max.

         value_type min()
         {
             . . .
         }
         template min(F) { final value_type min(F f)
         {
             . . .
         }}

 It seems to me that both of these are well named, and that to have

 names for the two would be perverse, or at least inconsistent.

 So, may we have overloads of template member functions, please? :-))

Templates already overload based on partial specialization rules. They don't overload with non-templates, because that is a major source of complexity, confusion, and bugs in C++.

I understand that, but it's got PITA consequences. Currently, I'm looking at a select method for containers (and ranges) that look something like: Container { <range> select(<delegate-predicate>); <range> select(<function-predicate>); template select(F) { <range> select(); } template select(F) { <range> select(F f); } Now, the first two work as overloads, but what I've been forced to do is declare the second ones with different names, as in: Container { <range> select(<delegate-predicate>); <range> select(<function-predicate>); template select0(F) { <range> select0(); } template select1(F) { <range> select1(F f); } The 0 and 1 are there until I think of something nicer, but you can see the unattractiveness of it. If you say to me right now that you'll *never* support overloads of template and non-template members, then I'll just work around it. I am a pragmatist, after all. But if there's wiggle room, I'd like to post this as some nice evidence for it. The two, more pressing issues, for me at the moment are: 1. the fact that a class template has to have every part of it (semantically?) correct before it can be accepted, and 2. the desire to have multiple member templates with the same name, being implicitly treated as properties (as per the other thread I raised last night.) Either of these being resolved would solve my select0!() / select1!() problem. I expect that the former has huge ramifications and is not going to be changed, so maybe we can have the latter ???
Jul 16 2004
parent "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cdabqf$um8$1 digitaldaemon.com...
 Templates already overload based on partial specialization rules. They


 overload with non-templates, because that is a major source of


 confusion, and bugs in C++.

I understand that, but it's got PITA consequences. Currently, I'm looking at a select method for containers (and ranges) that

 something like:

     Container
     {
         <range> select(<delegate-predicate>);
         <range> select(<function-predicate>);
         template select(F) { <range>    select(); }
         template select(F) { <range>    select(F f); }

 Now, the first two work as overloads, but what I've been forced to do is

 the second ones with different names, as in:

     Container
     {
         <range> select(<delegate-predicate>);
         <range> select(<function-predicate>);
         template select0(F) { <range>    select0(); }
         template select1(F) { <range>    select1(F f); }

 The 0 and 1 are there until I think of something nicer, but you can see

 unattractiveness of it.

Why not rewrite the first two select's as explicit template specializations?
 1. the fact that a class template has to have every part of it

 correct before it can be accepted, and

It has to be syntactically correct. When it is instantiated, then it needs to be semantically correct. Can you post a small canonical example of why this is causing a problem? I know I'm being very boring with my continual request for small examples <g>, but tiny examples with all the irrelevant stuff removed is very helpful for me to see exactly what the issue is without being distracted by anything else.
 2. the desire to have multiple member templates with the same name, being
 implicitly treated as properties (as per the other thread I raised last

 Either of these being resolved would solve my select0!() / select1!()

 expect that the former has huge ramifications and is not going to be

 maybe we can have the latter ???

I don't really understand what the "implicitly treated as properties" problem is. Which thread subject is it?
Jul 17 2004