I'm reading D specification, and I found:
"If a template has exactly one member in it, and the name of that member is
the same...".

That strikes me as strange.  It seems reasonable to use the name as a trigger for the Implicit template property feature, but what is the reason for the restriction to 'exactly one member'?

Neal Becker wrote:
> I'm reading D specification, and I found:
> "If a template has exactly one member in it, and the name of that member is
> the same...".
> 
> That strikes me as strange.  It seems reasonable to use the name as a
> trigger for the Implicit template property feature, but what is the reason
> for the restriction to 'exactly one member'?

Because the other names otherwise wouldn't be (externally) accessible any more, I guess.
Though that reason only applies when the others aren't private[1], which is why there have been suggestions to change this rule to "one _public_ member" instead of "one member"...


[1]: I'm not sure if private template members are accessible from the rest of the module they're declared in, like class & struct members. If they are, that might screw things up.

Frits van Bommel wrote:
> Neal Becker wrote:
>> I'm reading D specification, and I found:
>> "If a template has exactly one member in it, and the name of that member is
>> the same...".
>>
>> That strikes me as strange.  It seems reasonable to use the name as a
>> trigger for the Implicit template property feature, but what is the reason
>> for the restriction to 'exactly one member'?
> 
> Because the other names otherwise wouldn't be (externally) accessible any more, I guess.
> Though that reason only applies when the others aren't private[1], which is why there have been suggestions to change this rule to "one _public_ member" instead of "one member"...
> 
> 
> [1]: I'm not sure if private template members are accessible from the rest of the module they're declared in, like class & struct members. If they are, that might screw things up.

A possible alternative that I think has been proposed before would be to overload the meaning of 'this' for this purpose.  Then the rule could be "If a template has exactly one member in it, and the name of that member is the same, or if a template contains a 'this' member..."


Sean

Sean Kelly Wrote:

> Frits van Bommel wrote:
<snip>
>> [1]: I'm not sure if private template members are accessible from the rest of the module they're declared in, like class & struct members.  If they are, that might screw things up.
> 
> A possible alternative that I think has been proposed before would be to overload the meaning of 'this' for this purpose. Then the rule could be "If a template has exactly one member in it, and the name of that member is the same, or if a template contains a 'this' member..."

The problem is that the potential ambiguity remains.  Given this

    template Qwert(T) {
        class this {
            static int yuiop;
        }
        int yuiop;
    }

Now, is Qwert!(int).yuiop the member of the class or of the template?  Requiring the other members to be private wouldn't do it, because
(a) the class will most likely need to be able to distinguish between them
(b) private members are still accessible within the module (though adding a 'veryprivate' attribute that stops this would deal with this)

You could try adding a rule that no member of the implicit template member may have the same name as a member of the template.  But an ambiguity still remains: you can create aliases of template instances.  This ambiguity doesn't happen with the existing implicit member, because in the cases where it applies, the template instance and the implicit member thereof are one and the same thing.

Stewart.