On Wednesday, 20 January 2016 at 07:51:27 UTC, Manu wrote:
1. C++ has namespaces. They went and invented a whole 'nother
thing called modules. Evidently not even they think that
modules and namespaces are the same thing.
You admit that modules supersede namespaces. We have modules,
we use
modules as standard practise.
We don't need, or want, anything like namespaces.
Maybe you don't, but I remain quite confident that being able to
mimic the structure of the C++ code in D is valuable. One can
create a binding for a library and have it usable in a similar
fashion as it is in C++ from D.
This makes it nice to people that already know the library,
reduce the need for specific doc for the binding, and makes
maintenance of the binding much easier as it has the same
structure as the mapped C++ lib.
2. Multiple modules cannot have the same name in D.
I'm not sure what situation you're imagining where modules
would be created with the same names...?
How do you plan to map C++'s standard lib ? One giant hundred of
thousands of line C++ file ?
4. Modules and files have a 1:1 correspondence. This does not
work for namespaces.
I'm not sure what your point here is.
Are you arguing that C++ namespaces aren't expressible in D,
because
nothing can span modules? Of course, I agree completely. This
is a
good argument against trying to simulate C++ namespaces in D.
That doesn't make any sense.
5. "extern (C++) module std" ? Ugh.
Where did you pull that from? Nobody has ever suggested
anything like
that as far as I know.
Naturally, I strongly object to this too.
Well you still have to explain how the C++'s standard library is
going to be mapped with D module emulating C++'s namespaces.
7. Module semantics are independent of where they are
imported. Not so for namespaces.
I.e. if modules were bludgeoned into being namespaces,
Nobody has ever suggested anything like this.
You did that quite a few time yourself.
there would be such a
list of special cases and confusions and exceptions and
awkward crap you'd
be far, far better off having namespace as a SEPARATE feature,
because
that's what they'd wind up being anyway, even if they were
named "modules".
If this is what you're thinking, you've misunderstood literally
everything I've ever said on this topic.
The feature should be nothing more than this:
extern(C++, "ns") int x;
x is mangled with "ns". Namespace is a string, no conflict with
D
names is possible, organisation and disambiguation is the
business of
the author. Everything past that is needless complexity and
causes us
problems.
The extremely niche case where someone wants to declare 2
symbols with
the same name within the same module (in C++, they achieve this
using
2 namespaces), is easily solvable in various ways that a normal
D user
could use to resolve that desire in a pure D program, for
instance
(but not limited to) putting the second declaration in another
module.
The WHOLE point of namespace in C++ is to be able to have symbol
with the same name and not conflict.
Now you could say, put them in different modules and use the
modules to disambiguate, but then you'd use the C++ library in
quite a different way, meaning you need to write new doc and make
the work of the binding maintainer harder.
_all consequent problems_ are abolished instantly, all
behaviour is
exactly like normal D code, no surprises, no edge cases.
The code to do this must be a small fraction of the code
required to
implement the feature as it is today.
I don't expect so. All the resolution mechanisms required here
already exists in some form already. DMD may be kludged, but come
on, once something is defined a way, it is not possible to change
it, so please disregard DMD specificity here.
