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

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2004-02-17 11:54:23

{I will not try to take this any further as it is - as Dave pointed out 
- totally OT for boost. Anyway, I am just forwarding this message from 
Daveed as requested (my fault, I CC'ed him :), I suggest we take any 
further discussion to clc++m where Daveed opened an appropriate thread 
some time ago and has a chance to participate directly. Daniel}

From: David Vandevoorde <daveed_at_[hidden]>
Date: February 17, 2004 11:33:04 AM EST
To: Gabriel Reis <gdr_at_[hidden]>
Cc: Boost mailing list <boost_at_[hidden]>
Subject: Re: [boost] Re: [OT] Hiding template parameters [was: FC++ 
Formal review is...]

(I'm not on the Boost list.  Gabriel: Apologies if you
  get this twice.  I don't know if you're on the list.
  So to be sure, I left you on the recipients' list.)

On Feb 17, 2004, at 6:29 AM, Gabriel Dos Reis wrote:
[...]

 > Someone has characterized it as inconsistent without giving details as
 > to why; all I'm saying is that, if one accepts the principle that
 > "scopes nest", then the rule is a logical consequence, hence
 > consistent with that principle.

You're making one more assumption: That template
parameters really have their own full-fledged scope.
I say that they shouldn't, just as function parameters
don't.

 >  Now, it might be that that logical
 > consequence is unacceptable for some non-rational reasons, but that
 > does not mean the consequence itself is inconsistent.

The current situation is IMO unacceptable for
_rational_ reasons, no matter what the language-
legalistic arguments for it may be.

 > | The POV is that
 > |
 > | class B { typename X };
 > |
 > | template< typename X > class Y // 1
 > | : public B // 2
 > | { // 3
 > |    ...
 > | };
 > |
 > | You think that template parameter X is declared in line 1, then hidden
 > | by the base classes name introduced by line 2, thus non-accessible in
 > | line 3, right? You think of the name scopes to nest in the same order,
 > | do you?
 >
 > What I think is:  If we accept the principle that scopes should nest,
 > then we should accept its logical consequences; if don't want to
 > accept those logical consequences, then we should abandon the idea
 > that scopes nest.  Which one do you want to pick?

As mentioned above, I disagree that these are the
only options.  But even if you insist on thinking
in those terms, then there it is still possible
to come up with a mechanism that matches what most
of us expect: Simply consider the base class scope
to enclose the scope of the derived class parameters.

 > | This is a reasonable point of view, actually it's the current
 > | language's interpretation of the topic, but it's not what I call
 > | intuitive.
 >
 > One major problem is what is defined "intuitive" and when "intuitive"
 > is defeated by logic.

Oh please.  I notice you posted to the thread "Opinion
sought on name hiding issue" in comp.lang.c++.moderated.
Except for you, the other dozen participants seem to
have no problem on agreeing what is intuitive.

See above for what I think is the flaw in your logic.

 > | While it's technically correct, it still feels wrong - at
 > | least to me.
 >
 > If you think it is wrong, while being consistent with first principle,
 > then propose a a new first principle.  The worst thing to do, I
 > believe, is to introduce  barnacled hacks that comes from nowhere.
 >
 > | I see things more from a visibility-point-of-view. I
 >
 > "scopes nest" is visitbility-point-of-view :-)
 >
 > | can't see the base class' names at 2,
 >
 > yet, you see the following
 >
 >     struct A {
 >        struct iterator { };
 >     };
 >
 >     struct B : A {
 >        vodi f(iteraror);
 >     };
 >
 > don't you?  Or are you proposing that to be ill-formed?

I also see:

     struct A { typedef int I; };
     struct B: A {
         typedef long I;
     };
     struct C: B {
        I x;  // B::I hides A::I
     };

Same with template parameters: They hide the homonyms
in farther scopes.

 > We need general rules on which to decide, we don't need barnacled
 > hacks that would appear "intuitive" at a moment when we don't have a
 > working definition of "intuitive".
 >
 > | I have to go back (that is, I
 > | have to go one "scope" up) to see the names that are contained. This
 > | makes me think of the lines 1 and 2 to be swapped wrt the names they
 > | introduce into the scope of 3. To put it another way: The names of B
 > | are not declared at 2, and that line 2 is also not like a using
 > | declaration, although it might seem similar.
 > |
 > | If we use Dave's or my POV (and we are not alone ;), the advantages of
 > | scopes can be used in this example, too. The advantage is a smaller
 > | scope to search for a name: If you need to know what a name refers to,
 > | you just look into the scopes from the inside (nearest scope), to the
 > | outside. And it feels more natural to me if the scope of the template
 > | parameters is closer than the scope of the class' base(s).
 >
 > If the scope of the template-parameters should come after the scope
 > of base classes -- that is the way I understand you "is closer" --
 > then one would not be able to use template-parameters in base classes.

And you cannot: You can only use them to _name_ base
classes.  In fact, now that I reflect on it, base
classes are not really "enclosing scopes" of derived
classes.  You can simulate the lookup that way, but
you could just as well say that inheritance is a sort
of "base class using-directive" (which is how many
compilers implement it).

 > If you don't agree with the "scopes nest" principle, then propose
 > another principle, but please don't label it "intuitive" :-)

On the contrary: If that what Daniel's intuition says,
he should label it as intuitive.

 > If I were to design a new programming language, I'm not sure I would
 > just stick to  "scopes nest", but here we're not designing a new
 > programming language. IMO, one of the the worst things we can to the
 > already complex C++ scope rules, is to come up with yet another
 > special scope. At this point of complexity, following logical
 > consequences is less evil than "intuitive" hacks where we don't have
 > working definition of "intuitive".

You seem to imply that scope nesting is the only
mechanism that directs C++ name lookup.  That is
not the case though (using directives, using
declarations, and ADL don't work that way; inheritance
doesn't really work that way either).

Anyway, as many have pointed out, enabling sound
C++ engineering requires the current situation to
be fixed.

     Daveed