digitalmars.D - Implicit template properties
- Neal Becker (6/6) Mar 09 2007 I'm reading D specification, and I found:
- Frits van Bommel (9/16) Mar 09 2007 Because the other names otherwise wouldn't be (externally) accessible
- Sean Kelly (6/27) Mar 10 2007 A possible alternative that I think has been proposed before would be to...
- Stewart Gordon (14/24) Mar 10 2007 The problem is that the potential ambiguity remains. Given this
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'?
Mar 09 2007
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.
Mar 09 2007
Frits van Bommel wrote:Neal Becker wrote: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..." SeanI'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.
Mar 10 2007
Sean Kelly Wrote:Frits van Bommel wrote:<snip>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.[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..."
Mar 10 2007