This gives: "multmemtmpl.d(23): function expected before (), not 't dotexp
template instance Func!(int)'"

    class Thing
    {
    public:
        template Func(F)
        {
            F Func(F f)
            {
                return f;
            }

            F Func(F f1, F f2)
            {
                return f2;
            }
        }
    }

    int main()
    {
        Thing   t = new Thing;

        t.Func!(int)(10);

        t.Func!(int)(10, 20);

        return 0;
    }

A quick fix to this would be most appreciated. (I'm starting some real work for a new client next week, so it would be timely all round ...)


The alternate form, shown below, gives: "multmemtmpl2.d(13): template
Func(F) conflicts with Thing.Func(F) at multmemtmpl2.d(5)"


    class Thing
    {
    public:
        template Func(F)
        {
            F Func(F f)
            {
                return f;
            }
        }

        template Func(F)
        {
            F Func(F f1, F f2)
            {
                return f2;
            }
        }
    }

    int main()
    {
        Thing   t = new Thing;

        t.Func!(int)(10);

        t.Func!(int)(10, 20);

        return 0;
    }

>    class Thing
>    {
>    public:
>        template Func(F)
>        {
>            F Func(F f)
>            {
>                return f;
>            }
>
>            F Func(F f1, F f2)
>            {
>                return f2;
>            }
>        }
>    }
>
>    int main()
>    {
>        Thing   t = new Thing;
>
>        t.Func!(int)(10);
>
>        t.Func!(int)(10, 20);
>
>        return 0;
>    }
t.Func!(int).Func(10);
t.Func!(int).Func(10, 20);

Works just well for me.

Dont forget that template forms a kind of namespace for everything that is within..

"Takuan" <Takuan_member@pathlink.com> wrote in message news:cd9l8o$n89$1@digitaldaemon.com...
> >    class Thing
> >    {
> >    public:
> >        template Func(F)
> >        {
> >            F Func(F f)
> >            {
> >                return f;
> >            }
> >
> >            F Func(F f1, F f2)
> >            {
> >                return f2;
> >            }
> >        }
> >    }
> >
> >    int main()
> >    {
> >        Thing   t = new Thing;
> >
> >        t.Func!(int)(10);
> >
> >        t.Func!(int)(10, 20);
> >
> >        return 0;
> >    }
> t.Func!(int).Func(10);
> t.Func!(int).Func(10, 20);
>
> Works just well for me.

Really!? What version of DMD are you using?

Have you used the lines I posted verbatim? Please post your working code

> Dont forget that template forms a kind of namespace for everything that is within..

What's that got to do with the code sample given? Please explain.

In article <cd9q67$olv$1@digitaldaemon.com>, Matthew says...

[skip skip]

>Really!? What version of DMD are you using?
Digital Mars D Compiler v0.95

>Have you used the lines I posted verbatim? Please post your working code
>
>> Dont forget that template forms a kind of namespace for everything that is within..
>
>What's that got to do with the code sample given? Please explain.

Uh.. when do do Foo!(int) in your code you get template instantiated,
now you would want to call function of this given instance.. do to that you
should do Foo!(int).Foo(args). Correct me if I am wrong.

Here goes my working code:

=== cut here ===
import std.c.stdio;

class A {
template Foo(T) {
T Foo(T a) { return a; }
T Foo(T a, T b) { return b; }
}
};


int main()
{
A a = new A();
printf("%d\n", a.Foo!(int).Foo(10));
printf("%d\n", a.Foo!(int).Foo(10, 20));

return 0;
}
=== cut here ===
Program output is:
10
20

As expected.
The only strange thing is that I dont need to make template public, it's
public by default somehow (or is this intended behavior?).

Gah! Silly of me not to think of that. Nonetheless, (it seems like) it's still a bug, as I'm needing the behaviour I've shown. I can't imagine many people being happy having all that extra eye-candy for notionally simple statements.

Walter. Can we have change the rule for implicit template properties from

    "If a template has exactly one member in it, and the name of that member is
the same as the template name, that member is assumed to be referred to in a
template instantiation"

to

    "If all the members of a template have the same name as the template name,
those members are assumed to be referred to in a template instantiation"

 ??

"Takuan" <Takuan_member@pathlink.com> wrote in message news:cd9rb9$osp$1@digitaldaemon.com...
> In article <cd9q67$olv$1@digitaldaemon.com>, Matthew says...
>
> [skip skip]
>
> >Really!? What version of DMD are you using?
> Digital Mars D Compiler v0.95
>
> >Have you used the lines I posted verbatim? Please post your working code
> >
> >> Dont forget that template forms a kind of namespace for everything that is within..
> >
> >What's that got to do with the code sample given? Please explain.
>
> Uh.. when do do Foo!(int) in your code you get template instantiated,
> now you would want to call function of this given instance.. do to that you
> should do Foo!(int).Foo(args). Correct me if I am wrong.
>
> Here goes my working code:
>
> === cut here ===
> import std.c.stdio;
>
> class A {
> template Foo(T) {
> T Foo(T a) { return a; }
> T Foo(T a, T b) { return b; }
> }
> };
>
>
> int main()
> {
> A a = new A();
> printf("%d\n", a.Foo!(int).Foo(10));
> printf("%d\n", a.Foo!(int).Foo(10, 20));
>
> return 0;
> }
> === cut here ===
> Program output is:
> 10
> 20
>
> As expected.
> The only strange thing is that I dont need to make template public, it's
> public by default somehow (or is this intended behavior?).
>
>

"Matthew Wilson" <admin.hat@stlsoft.dot.org> wrote in message news:cd9j01$m8k$1@digitaldaemon.com...
> This gives: "multmemtmpl.d(23): function expected before (), not 't dotexp
> template instance Func!(int)'"
>
>     class Thing
>     {
>     public:
>         template Func(F)
>         {
>             F Func(F f)
>             {
>                 return f;
>             }
>
>             F Func(F f1, F f2)
>             {
>                 return f2;
>             }
>         }
>     }
>
>     int main()
>     {
>         Thing   t = new Thing;
>
>         t.Func!(int)(10);
>
>         t.Func!(int)(10, 20);
>
>         return 0;
>     }
>
> A quick fix to this would be most appreciated. (I'm starting some real
work
> for a new client next week, so it would be timely all round ...)

The error is correct, if a bit obscure. To get the name promotion from template scope up, there can be only one declaration in the template. Rewriting the function calls as:

         t.Func!(int).Func(10);
         t.Func!(int).Func(10, 20);

should solve it.


>
> The alternate form, shown below, gives: "multmemtmpl2.d(13): template
> Func(F) conflicts with Thing.Func(F) at multmemtmpl2.d(5)"
>
>
>     class Thing
>     {
>     public:
>         template Func(F)
>         {
>             F Func(F f)
>             {
>                 return f;
>             }
>         }
>
>         template Func(F)
>         {
>             F Func(F f1, F f2)
>             {
>                 return f2;
>             }
>         }
>     }
>
>     int main()
>     {
>         Thing   t = new Thing;
>
>         t.Func!(int)(10);
>
>         t.Func!(int)(10, 20);
>
>         return 0;
>     }

That's also correct, since you have two templates that are not distinguishable, since they have the same name and same parameter lists.

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cd9sil$p6d$1@digitaldaemon.com...
> Gah! Silly of me not to think of that. Nonetheless, (it seems like) it's
still a
> bug, as I'm needing the behaviour I've shown. I can't imagine many people
being
> happy having all that extra eye-candy for notionally simple statements.
>
> Walter. Can we have change the rule for implicit template properties from
>
>     "If a template has exactly one member in it, and the name of that
member is
> the same as the template name, that member is assumed to be referred to in
a
> template instantiation"
>
> to
>
>     "If all the members of a template have the same name as the template
name,
> those members are assumed to be referred to in a template instantiation"
>
>  ??

It sounds like a good idea. I'll add it to the 2.0 queue.

"Walter" <newshound@digitalmars.com> wrote in message news:cd9urv$prm$2@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cd9sil$p6d$1@digitaldaemon.com...
> > Gah! Silly of me not to think of that. Nonetheless, (it seems like) it's
> still a
> > bug, as I'm needing the behaviour I've shown. I can't imagine many people
> being
> > happy having all that extra eye-candy for notionally simple statements.
> >
> > Walter. Can we have change the rule for implicit template properties from
> >
> >     "If a template has exactly one member in it, and the name of that
> member is
> > the same as the template name, that member is assumed to be referred to in
> a
> > template instantiation"
> >
> > to
> >
> >     "If all the members of a template have the same name as the template
> name,
> > those members are assumed to be referred to in a template instantiation"
> >
> >  ??
>
> It sounds like a good idea. I'll add it to the 2.0 queue.

:(

That'll be one of several things that'll push DTL to 2.0, then.

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cd9vo4$q10$1@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message news:cd9urv$prm$2@digitaldaemon.com...
> > >     "If all the members of a template have the same name as the
template
> > name,
> > > those members are assumed to be referred to in a template
instantiation"
> > >
> > >  ??
> >
> > It sounds like a good idea. I'll add it to the 2.0 queue.
>
> :(
>
> That'll be one of several things that'll push DTL to 2.0, then.

Why? The solution is a bit more typing, which can be alleviated with aliases. It shouldn't be a showstopper. The only way I can get 1.0 out is to stop adding more features (this one above isn't trivial) and work on making what D has work well and smoothly.

"Walter" <newshound@digitalmars.com> wrote in message news:cda3qv$r0r$1@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cd9vo4$q10$1@digitaldaemon.com...
> >
> > "Walter" <newshound@digitalmars.com> wrote in message news:cd9urv$prm$2@digitaldaemon.com...
> > > >     "If all the members of a template have the same name as the
> template
> > > name,
> > > > those members are assumed to be referred to in a template
> instantiation"
> > > >
> > > >  ??
> > >
> > > It sounds like a good idea. I'll add it to the 2.0 queue.
> >
> > :(
> >
> > That'll be one of several things that'll push DTL to 2.0, then.
>
> Why? The solution is a bit more typing, which can be alleviated with aliases. It shouldn't be a showstopper. The only way I can get 1.0 out is to stop adding more features (this one above isn't trivial) and work on making what D has work well and smoothly.

Yeah, I was just being hysterical. (<philological>Has that term been banned over there yet? I am aware it's seen as being anti-woman in some growing circles.</philological>)

I'm suffering something of a flood of problems here, so I can only aim low at the moment, which I'll try to do in the next day or so, and then crank it up as we progress the compiler and/or the language and/or my understanding.

Having said that, the current low mark will still be pretty sweet. ;)