[boost] Re: Re: Re: [OT] Hiding template parameters [was: FC++Formalreview is...]

From: Andy Little (andy_at_[hidden])
Date: 2004-02-17 09:15:35

"Gabriel Dos Reis" <gdr_at_[hidden]> wrote in message
news:m31xougf9h.fsf_at_uniton.integrable-solutions.net...
> "Andy Little" <andy_at_[hidden]> writes:
>
> | "Gabriel Dos Reis" <gdr_at_[hidden]> wrote
> | > David Abrahams <dave_at_[hidden]> writes:
> | >
> | > | > 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.
> | >
> | > But function parameters are not template parameters vice versa. And
> | > you should not expect them to behave the same without providing
> | > technical reasons why such expectations may take place.
> |
> | Strikes me that one of C++ s problems is that the namespace system
(which
> | itself partly resulted from confusion over C struct space) does not
really
> | formally address the fact that there are many different kinds of
'space', as
> | examples(simplifying)  object-space, type-space and template-space.
>
> 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
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  :-)

regards
Andy Little