Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
David Abrahams <dave@boost-consulting.com> writes:
| Brian McNamara <lorgon@cc.gatech.edu> writes: | | > Apologies ahead of time if I am putting words in anyone's mouth. | > | > I think Dave wants to imply that the class T in his example is not | > allowed to have a member named U according to Gaby's proposed rule. | | That's what I thought he meant.
But then, your remark about "would be horrible for generic program" is, ahem, puzzling. You still did not explain why.
Well, if my understanding of your proposed rule had been correct, it would've meant that the names of a template's parameters would leak out into requirements on its arguments (that they not have nested members with that name).
| > But this isn't how the rule would work; the way I see it, _these_: | > | > struct Base { typedef int U; }; | > | > template <class U> | > struct Derived : Base { }; // illegal | > | > struct Derived2 : Base { | > template <class U> | > void f(U u) {} // illegal | > }; | > | > would be illegal ("the name U already has another meaning; choose | > another name for your template parameter"), whereas _these_: | > | > struct Base { typedef int U; }; | > | > template <class B, class U> | > struct Derived : B { }; | > /* ... Derived<Base> ... */ | > | > template <class B> | > struct Derived2 : B { | > template <class U> | > void f(U u) {} | > }; | > /* ... Derived2<Base> ... */ | > | > are both fine, since Base's "U" is hidden by virtue of being a dependent | > name. There is still an issue of what happens if one of these last two | > classes issues a "using B::U" in its body; presumably then "U" ought to | > become outlawed as a valid template parameter name. | > | > Just my two cents here... | | OK, I think I understand now. I think it's a bizarre and inconsistent | rule.
What is bizarre and inconsistent about it and is not with the other alternatives you care to name?
As I expected my example below to demonstrate, I think it's inconsistent with the way names from non-dependent base classes are dealt with when masked by function parameter names. Up till now, the only way that changing the name of a private member could break a derived class (AFAIK) is if the member were virtual. IIUC your proposed rule would add another one.
This question is not rhetorical. When you register strong opinons about a technical issue or throw in the air fashionable words like "generic programming",
Generic Programming went out of style around here about 7 weeks ago. It's so, like, 2003.
the least that could be expected is that you provide technical explanation.
I just misunderstood your proposal, Gaby, and in that light I thought the meaning behind my remarks to be "obvious".
| Shall we outlaw: | | struct Base { static int x; }; | | struct Derived : Base { | void f(int x) {} // Horrors! we're masking a base class member!
If you happen to pause a second and have look at the issue at hand, I'm confident that you'll see the difference between the case we're discussing and your example.
Of course I see the difference; they use different language features. I also see the analogy. I honestly don't see why the other case would warrant a diagnostic, while this one doesn't. Why is the difference between a member template parameter and a function parameter significant?
| }; | | Sorry for the sarcasm;
And, I'm pretty sure you know sarcasm is not appropriate for tehcnical discussions.
Sorry, I'm not at my best. Now returning to proper decorum. -- Dave Abrahams Boost Consulting www.boost-consulting.com