extern(C++, ns)

[deadalnix via Digitalmars-d]

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.