Template Usage with Eponymous Trick

ShadoLight ettienne.gilbert at gmail.com
Sun Feb 2 13:01:26 UTC 2020


On Friday, 31 January 2020 at 15:37:06 UTC, Steven Schveighoffer 
wrote:
> On 1/30/20 9:10 AM, ShadoLight wrote:
>

> but to give you some historical perspective...

[..]

>
> It was actually much more restrictive before -- e.g.  in order 
> to do an eponymous template, you could have no other members in 
> the template.

Thanks for the historical perspective Steve. Appreciated.

When you refer to 'other members' in the eponymous template, I 
notice that they are indeed allowed, but are effectively hidden 
(if they have a different name from the template name) inside the 
eponymous template, correct?

For example, this works fine in 'classical' template style - all 
members are 'public' and accessible:

template bar(T) {
     T z;                  //Allowed...
     void b1(T x){z+=x;}   //Allowed...
     void b2(T x){z-=x;}   //Allowed...
}
void main()
{

     bar!(int).b1(4);    //Works..
     writeln(bar!int.z); //Works..
     bar!(int).b2(5);    //Works..
     writeln(bar!int.z); //Works..
}


For eponymous templates, only members with the overloaded 
template identifier are accessible 'from the outside'.


template foo(T) {
     T z;                  //Allowed...
     void foo(T x){f1(x);} //Allowed...
     T foo(){return z;}    //Allowed...
     void f1(T x){z+=x;}   //Allowed...
}


void main()
{
     foo(3);              //Works..
     foo(4);              //Works..
     writeln(foo!int.z);  //onlineapp.d(21): Error: no property z 
for type int
     foo!int.f1(3);       //onlineapp.d(21): Error: no property f1 
for type int
     writeln(foo!int());  //Works..
}

So the eponymous template invocation has to use the eponymous 
'trick' and only overloaded members are accessible.

Not bad and definitely an improvement , but I still find the 
inconsistency jarring... IIUC this 'ambiguity' would have been 
avoidable if template argument braces were not optional, right?

I do know this horse has bolted, but personally I think it D made 
a mistake to make the braces on compile-/run-time arguments on 
template/function invocation optional in the zero/one argument 
case.

It is not even completely symmetric between compile- and 
run-time: in compile time you can leave the braces off in the 
case of zero and one arguments, but for run-time only for zero 
arguments.

For want of the effort to type 2 braces, a fair bit of complexity 
and some inconsistency has been introduced into the language. And 
I remember that it actually made code harder to read when I 
started out in D, not easier.

I support the dropping of the braces in the case of property 
functions, but that use case is quite clear-cut and I think easy 
to handle based on the @property annotation.



More information about the Digitalmars-d-learn mailing list