John Max Skaller (maxtal@physics.su.OZ.AU) wrote:
[text from my original message deleted]
:  The problem with using namespaces as module is that
: namespaces are not "closed" but "open". Modules must be closed,
: like classes. Preferably, they should be open like classes
: as well. (Open/Closed principle of modules)

If C++ doesn't have a separate module support, people will probably use
namespaces as modules anyway.
The point in my suggestion was that there should be some other mechanism
than '#include' to import namespace interfaces from external files. This
is because '#include' means including files as text, and code written for
some compiler having a module-based compilation system will be
compiler-dependent, because it can't use '#include' for importing modules.

:  The problem with adding modules (even given a good design),
: is that the language C++ would be overly complicated and burdened
: by two "similar" concepts (modules and namespaces).

I think that namespaces offer a quite well and efficient way to create
modules. The only thing that I dislike is the way that modules are imported
(i.e. #including text files). In addition, I would like to get rid of the
#ifndef...#endif stuff in the beginning and end of a module.

[...]

BTW, here is an improved version of my original suggestion:

1.
The following syntax would be used to tell the compiler where to get an
external namespace or class:

path "filename" namespace A;
path "filename" class B;
('#pragma path' could be used, too)

The filename would be given without an extension. The compiler would
append the correct extension depending on its compilation system.

Namespaces and classes could also be renamed when they are imported. That
is, the importing code could give a namespace or a class a different name.
For example:
path "RangeCheckedArrays" namespace Arrays = RangeCheckedArrays;

2.
The path declaration would not itself import anything. It would just
tell the compiler where to find the interface if it is used.
If you wanted to use a namespace/class, you would use the following kind of
declarations in addition to 'path':
  class OwnClass;
  namespace OwnModule;
These kind of declarations would be handled specially if the 'path'
declaration had been used for the respective namespace or class.
The effect of the declaration 'namespace OwnModule;' would then be
exactly the same as if the interface of the namespace 'OwnModule' had
been written in the same place. The only difference would be that the
compiler would have to get the interface from a header file (or from some
compiled module file).

3.
The namespace/class implementation (source code) file would need to tell
the compiler which interface it implements. It would be done as follows:

// The source code file begins.
implementation "interface-file"
// The normal implementation of the module.
..

4.
The interface (header) file would not need any '#ifndef''s to guarantee
that it is included only once. The path declaration would take care of this.

***

This system would have the following advantages compared to '#include''s:
+ Compilers could use a module-based compilation system without forcing
the programmers to change their source code.
+ As filenames are system-dependent, the path declaration is also
system-dependent (and so is #include). However, because the path
declarations would not actually import anything, they could be collected
to a single file. The number of system-dependent files would be reduced
this way.

 Tommi H|yn{l{nmaa