"Andy Little" <andy@servocomm.freeserve.co.uk> writes: | > I'm sorry, I cannot undersand what you mean here. | | The reference is in D&E 3.12 2/3rd way in (example struct outer{struct inner | ... ) C had(has?) a different take on nested scopes. | | My point is more general. As laid out in the standard scope rules are | dependent on context, however there is no overall vision of the concept | behind why certain rules apply in a given context. What you have is a large | number of bits and pieces hinting at the greater picture. As it stands you I usually describe that as "a long list of special cases", but I would not go that far saying that there is no overall vision of the concept behind why certain rules apply in a given context. Each time I've asked why certain rules don't apply, I think I've got an answer as to why. But, there are situations where general rules are prevalent. It looks to me that this issue of members hide enclosing template-parameters is one where a general rule applies. | just have to know All the rules... nobody really does... hence confusion. In | order to provide concepts rather than intuition as a guide to what rules to | apply in a given situation, there should be some hierarchy of entities. I | would put the first branch off the root of the tree at template versus non | template. What that means is that on the template branch Dont expect the | same rules as on the non template branch. From there function/class giving | 4 contexts each again with its own rules. There is no crossover of rules | from one context to another. However travelling down from the root there | should be consistency of rules. One rule at top of the template branch | Might be that 'new' template parameters should hide names from 'older' | scopes. The rationale being that the template parameters are the most | prominent part of a template definition. | | Whatever... template 'space' just aint the same as non template 'space'... | so there should be no crossover of rules between different contexts. e.g you | cant apply rules from a non-template function to a function template etc. | | This sounds like a recipe for an explosion of rules, but in fact many rules | that apply in one context would *look very similar* to rules that applied in | other contexts. However there is no Requirement that that must be the case. | | The tree models language syntax | Template branch.: template<..> T ---> {function template} | template<..> class -->{ class template} | Non-template branch T --->{function} class ---> {class}; | | (Next branch from root to be 'concept' ...) ;-) | | All these entities are entirely different animals. | | Hope the above makes some sense. It does to me anyways :-) I see now what you meant. Thanks for taking the time to clarify. Your picture leave out whether you consider nesting of scopes or not. -- Gaby