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.)

"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? :-))

"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++.

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

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