• "Jarrett Billingsley" <kb3ctd2 yahoo.com> Dec 23 2006
• Bill Baxter <dnewsgroup billbaxter.com> Dec 23 2006
• Frits van Bommel <fvbommel REMwOVExCAPSs.nl> Dec 23 2006
• Daniel Keep <daniel.keep+lists gmail.com> Dec 23 2006
• Thomas Kuehne <thomas-dloop kuehne.cn> Dec 23 2006

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

You can do this:

template Foo()
{
    const uint Foo = 5;
}

...

uint x = Foo!();

And it automatically looks up Foo!().Foo because it has one member named the 
same as the template.

What I'm suggesting is that the "have one member" part be changed.  I've 
written and seen a lot of template code that does stuff like this:

template SomethingImplementation(T, U)
{
    alias Blah!(T) myBlah;
    alias Boo!(U) myBoo;

    ...

    const uint result = someNumber;
}

template Something(T, U)
{
    alias SomethingImplementation!(T, U).result Something;
}

That is, an "implementation" template to do all the work, which has several 
members, and an "interface" template to make it easier to call the 
implementation template.  Pretty kludgy.

Would it really break anything if the rule were changed so that it would 
always just look for a member of the same name of the template, no matter 
how many members the template has? 

Bill Baxter <dnewsgroup billbaxter.com> writes:

Jarrett Billingsley wrote:
 You can do this:
 
 template Foo()
 {
     const uint Foo = 5;
 }
 
 ...
 
 uint x = Foo!();
 
 And it automatically looks up Foo!().Foo because it has one member named the 
 same as the template.
 
 What I'm suggesting is that the "have one member" part be changed.  I've 
 written and seen a lot of template code that does stuff like this:


Yes, this would be very nice to have.

I find myself wishing frequently I could do something like that when 
dealing with non-trivial return/parameter types.

template something(T) {
    alias [...] Ret;
    alias [...] A;
    alias [...] B;
    Ret something(A a, B b) { ... }
}

Where the [...]'s are things like typeof(T.member) or other such 
statically determined type based on T.

--bb

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

Jarrett Billingsley wrote:
 You can do this:
 
 template Foo()
 {
     const uint Foo = 5;
 }
 
 ...
 
 uint x = Foo!();
 
 And it automatically looks up Foo!().Foo because it has one member named the 
 same as the template.
 
 What I'm suggesting is that the "have one member" part be changed.  I've 
 written and seen a lot of template code that does stuff like this:


This has been proposed before, but (IIRC) with the added qualification 
that all other members should be private for it to work. Still hasn't 
happened though :(.

Daniel Keep <daniel.keep+lists gmail.com> writes:

Frits van Bommel wrote:
 Jarrett Billingsley wrote:
 
 You can do this:

 template Foo()
 {
     const uint Foo = 5;
 }

 ...

 uint x = Foo!();

 And it automatically looks up Foo!().Foo because it has one member 
 named the same as the template.

 What I'm suggesting is that the "have one member" part be changed.  
 I've written and seen a lot of template code that does stuff like this:


 
 This has been proposed before, but (IIRC) with the added qualification 
 that all other members should be private for it to work. Still hasn't 
 happened though :(.


Mmm; I agree with the extra restriction: the implicit property works iff 
the template has exactly one public member with the same name as the 
template itself.

	-- Daniel

Thomas Kuehne <thomas-dloop kuehne.cn> writes:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Keep schrieb am 2006-12-23:
 Frits van Bommel wrote:
 Jarrett Billingsley wrote:
 
 You can do this:

 template Foo()
 {
     const uint Foo = 5;
 }

 ...

 uint x = Foo!();

 And it automatically looks up Foo!().Foo because it has one member 
 named the same as the template.

 What I'm suggesting is that the "have one member" part be changed.  
 I've written and seen a lot of template code that does stuff like this:


 
 This has been proposed before, but (IIRC) with the added qualification 
 that all other members should be private for it to work. Still hasn't 
 happened though :(.


 Mmm; I agree with the extra restriction: the implicit property works iff 
 the template has exactly one public member with the same name as the 
 template itself.


The public-restriction is too weak.

#
# struct Foo{ int i = 1; }
#
# template Bar(){
#     private int i = 2;
#     public Foo Bar;
# }
#
# [...]
#
# int x = Bar.i; // 1 or 2?

If implemented, it should be:

The implicit property works if the template has exactly one accessible
member and this member has the same name as the template.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFFjdSLLK5blCcjpWoRArP6AJwIcyaiq7aN7DiYmNhiBc+tGUWpFACfcvGZ
37rJXPTczha/RJ9xjps5ytU=
=nl1h
-----END PGP SIGNATURE-----