> I once read a proposal to add inherited'' to the language, but it
> was turned down, since the language alread supports it using a typedef:
Now I know: the inherited-discussion was in
'ctor/dtor behaviour for ordinary member functions'

Fergus Henderson wrote a reason why 'inherited' would allow things
that can't be done by typedef (with reasonable effort):
> Huh?  A keyword inherited WILL work with multiple inheritence.
> It seems that some people are having trouble understanding this
> point, so let me give an example:
>
>         struct Base1 {
>                 foo();
>         };
>         struct Base2 {
>                 bar();
>         };
>         struct Derived : Base1, Base2 {
>                 baz() {
>                         inherited::foo();       // calls Base1::foo();
>                         inherited::bar();       // calls Base2::foo();
>                 }
>         };
>
> This example, like the vast majority of real-world examples where
> 'inherited::' might be used, just simply WORKS.

Yes, introducing 'inherited' would not buy much, but you have to say that it
would buy more than nothing. To me 'inherited' (as proposed) is not worth
introducing as it has such a limited usage (i.e. inheritance).

I was just trying to propose to the ones who are arguing for 'inherited':
 If you want to extend C++ by introducing a new mechanism and a new keyword
 like 'inherited' than you should at least consider if this mechnism/keyword
 can have a more general useage than just the one you originally thought of.
 If you can think of enough usages maybe than you can persuade the others
 that your mechanism/keyword is worth introducing.

Like 'inherited' works with multiple inheritance whereas 'typedef Base inherited'
does not, I gave an example where 'upper' could do something that can not be
done now: (But this does not mean that I would perfere that one may do this)

int f ()
{ for(int x=0; x<MAX_X; x++)
 { bool something;
  // ...
  if( something )
  { // a new x is introduced and
   // compared to the x of outer block
   for(int x=upper::x-1; x<upper::x+1; x++)
   { // ...
   }
  }
 }
}
I don't know any way to get access to a name defined inside a compound-statement
(block) that is hidden by a later redefinition of that name in a new compound-
statement that is nested in the former one. The reason is that compound-statements
don't have a (namespace-)name that could be used for qualified access.

--------------------------------------------------------------------
Ulf Sch   nemann
schuenem@informatik.tu-muenchen.de
Institut f   r Informatik, Technische Universit   t M   nchen.