digitalmars.D.bugs - Cannot overload member template functions

Matthew Wilson (14/14) Jul 15 2004 template detect(F) { final bool detect(F f)

Matthew Wilson (15/27) Jul 15 2004 Now I'm on an example that does seem like overloads should be allowed, m...

Walter (6/19) Jul 16 2004 different

Matthew (33/55) Jul 16 2004 I understand that, but it's got PITA consequences.

Walter (20/49) Jul 17 2004 don't

"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

"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

"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

different
 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

"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

 different
 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

"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


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.

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

(semantically?)
 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

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 ???

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

Jul 17 2004

D Programming

C/C++ Programming

Other

digitalmars.D.bugs - Cannot overload member template functions