Re: Nested namespace syntactic sugar
Manfred von Willich wrote:
I would propose this syntactic sugar be introduced in the standard,
such the following two constructs be treated as identical in all
contexts (extended to any level of nesting):
namespace spaceX::spaceY { ...other stuff... }
and
namespace spaceX { namespace spaceY { ...other stuff... } }
From searching the various issues lists
(http://www.open-std.org/JTC1/SC22/WG21), I am aware that there is a
related issue (closed issues list rev 41, issue 311), however I think
in this, I concur with Jonathan Caves. There may be ongoing work in
this area, of which please let me know (I'm not sure how to access such
work). In raising this this form, I hope I will not be reviving old
arguments.
My argument is as follows:
- The construct cannot occur in code conforming to the existing
standard, and it thus cannot break existing code.
- No new keyword are needed.
- Non-compliant compilers that do accept it almost certainly use a
compatible interpretation
- There is valuable utility in the change: It is a pain to have code
in which the "correct" indentation is large, and changes when the
namespace hierarchy is changed.
- Other languages successfully use the equivalent (e.g. C#, Java's
"package")
Treating this a pure syntactic sugar (i.e. the interpretation maps
directly to an existing construct), I do not see room for
misinterpretation. Thus, it should be allowed when declaring
namespaces and when reopening them.
The double colon operator (::) in C++ usually separates names that have
already been defined. That is, by the time X::A appears in a source
file, X has either been declared a class or namespace and A has already
been declared within it. Granted, there is at least one exception: a
friend declaration can introduce a new name through a colon declaration
- although this result is often not what the programmer intended.
Nevertheless having a double colon appear in a declaration (instead of
in a definition for a previous declaration) would be another (and more
significant) exception to this convention - and would of course further
complicate the task of parsing C++ code. The fact that the construct is
"syntactic sugar" does not necesarily make it easier to parse - but
certainly makes an argument against adopting it - since it adds nothing
that is not already supported in the language.
All other issues aside, I would question the alleged benefit itself:
that is, whether streamlining nested namespace declarations is a
desirable goal. I argue that it is not. I think that declaring deeply
nested namespaces in C++ should be something of a chore - because
writing client code that uses deeply nested names is not in the least
convenient. In other words, there is cost in creating nested namespaces
that should not minimized for anyone inclined to make such
declarations. So if some implementor is determined to declare a set of
nested namespaces five levels deep - I would rather have them have to
open each namespace explicitly and do so five times - because there is
a greater chance that at some point in this process they may ask
themselves: "hmmm...do I really this many levels of namespaces?"
Whereas if the task can be accomplished with a one-line declaration -
then the chance that that question would ever be raised is remote. And
in that case it would be clients of this interface who would be the
ones to bear the cost of this convenience.
Greg
---
[ 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.comeaucomputing.com/csc/faq.html ]