Hans,

I believe this to be an excellent idea.  I posted a similar request about a
month or so ago, but was completely ignored.  I believe this to be a most
significant improvement to the language, as it allows the substitution of
types from other namespaces without a large cut and paste operation, and
without typedef'ing new types just to be able to use existing types.

I was also pondering the downside you mentioned.  The return types are not
in the class scope currently, and this is sometimes detrimental to
syntactical clarity anyhow.  I wonder if it would be possible to make the
return type within class scope too, without breaking lots of existing code.
If we could do this then we could probably have just one using clause per
class definition and implementation; otherwise we probably would have to
have two and keep them in synchronisation.  This is still IMHO superior to
the disasterous long fully qualified symbols in header files we have
currently.

Good show Hans!

Neil Groves

I think if the using clause is in the class scope then the whole class scope
should be affected.
"Hans Salvisberg" <z1@salvisberg.com> wrote in message
news:3ecb9137_4@news.bluewin.ch...
> There haven't been any new posts in my thread "Why are using directives
not
> allowed at class scope?" for a week, and no one has voiced any reason
> against using-directives at class scope, so please allow me to make this
> proposal:
>
>
> Allow Using-Directives in Class Scope
>
> Change the sentence
>
>     "A using   directive shall not appear in class scope, but may appear in
> namespace scope or in block scope."
>
> at the beginning of [namespace.udir] to
>
>     "A using   directive may appear in namespace scope, block scope, or in
> class definitions (class scope)."
>
>
> Interpretation:
>
> A using-directive in a class definition would make the names from the
named
> namespace available in the enclosing class scope, meaning
>   -- the class definition (including implicit inline functions),
>   -- the parameter lists and function bodies of member function
definitions,
> and
>   -- the class scope of derived classes
>
>
> Benefits:
>
> 1. This could relieve the class definition of lots of namespace
qualifiers,
> specifically for namespace ::std, but also for other namespaces the class
is
> related to.
>
> 2. It could relieve member function definitions of lots of namespace
> qualifiers, both in their parameter lists and in their bodies, especially
> for function definitions in header files, such as out-of-line inline
member
> functions and template member functions, where file scope using-directives
> are very undesired.
>
> 3. It would let the programmer clearly and succinctly state their intent
> such as "this class uses the Standard Library and any unqualified Standard
> Library names really do refer to names in the Standard Library" by
including
> a single
>
>     using namespace std;
>
> in the class definition (preferably at the top).
>
> 4. It would let the programmer avoid namespace pollution with minimal
effort
> (global namespace as well as any named namespace the class might be
> contained in).
>
>
> Downside:
>
> The return types of out-of-line member function definitions are not within
> class scope, so we would still need to use namespace qualifiers for these.
> However, the compiler would be able to catch any inconsistencies, because
> the return types of the member function declarations are within the class
> scope.
>
>
> Open question:
>
> Should a class scope using-directive take effect from its position
> downwards, or should it affect the entire class scope, including the
region
> in the class definition above the using-directive? Or should class scope
> using-directives only be allowed at the top of class definitions?
>
>
> Existing code:
>
> This proposal would not break any existing code, because it introduces new
> optional syntax (in a clearly defined context) that used to be
specifically
> prohibited.
>
> (end of proposal)
>
>
> I believe this would nicely complement "auto" and the two would go a long
> way towards putting the fun back into C++ programming as well as improving
> readability and maintainability. Also, it would fit gracefully into the
> overall model of the language.
>
> Please comment... Thanks!
>
> Hans
>
>
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

There haven't been any new posts in my thread "Why are using directives not
allowed at class scope?" for a week, and no one has voiced any reason
against using-directives at class scope, so please allow me to make this
proposal:


Allow Using-Directives in Class Scope

Change the sentence

    "A using   directive shall not appear in class scope, but may appear in
namespace scope or in block scope."

at the beginning of [namespace.udir] to

    "A using   directive may appear in namespace scope, block scope, or in
class definitions (class scope)."


Interpretation:

A using-directive in a class definition would make the names from the named
namespace available in the enclosing class scope, meaning
  -- the class definition (including implicit inline functions),
  -- the parameter lists and function bodies of member function definitions,
and
  -- the class scope of derived classes


Benefits:

1. This could relieve the class definition of lots of namespace qualifiers,
specifically for namespace ::std, but also for other namespaces the class is
related to.

2. It could relieve member function definitions of lots of namespace
qualifiers, both in their parameter lists and in their bodies, especially
for function definitions in header files, such as out-of-line inline member
functions and template member functions, where file scope using-directives
are very undesired.

3. It would let the programmer clearly and succinctly state their intent
such as "this class uses the Standard Library and any unqualified Standard
Library names really do refer to names in the Standard Library" by including
a single

    using namespace std;

in the class definition (preferably at the top).

4. It would let the programmer avoid namespace pollution with minimal effort
(global namespace as well as any named namespace the class might be
contained in).


Downside:

The return types of out-of-line member function definitions are not within
class scope, so we would still need to use namespace qualifiers for these.
However, the compiler would be able to catch any inconsistencies, because
the return types of the member function declarations are within the class
scope.


Open question:

Should a class scope using-directive take effect from its position
downwards, or should it affect the entire class scope, including the region
in the class definition above the using-directive? Or should class scope
using-directives only be allowed at the top of class definitions?


Existing code:

This proposal would not break any existing code, because it introduces new
optional syntax (in a clearly defined context) that used to be specifically
prohibited.

(end of proposal)


I believe this would nicely complement "auto" and the two would go a long
way towards putting the fun back into C++ programming as well as improving
readability and maintainability. Also, it would fit gracefully into the
overall model of the language.

Please comment... Thanks!

Hans



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hans Salvisberg wrote:
> There haven't been any new posts in my thread "Why are using directives
> not allowed at class scope?" for a week, and no one has voiced any reason
> against using-directives at class scope, so please allow me to make this
> proposal:

Slightly-related, i've got one as well:

In day-to-day use, nesting of namespaces becomes a problem for me, mainly
because my editors (x/emacs) indent another level for each namespace. After
2 or 3 levels it makes editing quite difficult without a very high-res
monitor to fit it all on. i understand this is an "editor/user problem",
not strictly a language problem, but it is a problem which certainly
affects almost every coder out there, and thus could (at some level) be
interpretted as a shortcoming of the language (i.e., a way in which the
language works against the coder, instead of for him/her). My proposal is
to allow this construct to declare a namespace:

namespace foo::bar {

}
as opposed to:

namespace foo {
    namespace bar {
    }
}

i can see some one or two immediate problems with this (for example,
potentially extra work to determine if namespace foo has already been
declared), but i really believe it would be an improvement, in
programmer-work terms, to allow this syntax for declaring nested
namespaces.

--
----- stephan beal
Registered Linux User #71917 http://counter.li.org
I speak for myself, not my employer. Contents may
be hot. Slippery when wet. Reading disclaimers makes
you go blind. Writing them is worse. You have been Warned.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]