extern(C++, ns)

Manu via Digitalmars-d digitalmars-d at puremagic.com
Wed Jan 20 15:35:31 PST 2016


On 21 January 2016 at 01:32, Simen Kjaeraas via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Wednesday, 20 January 2016 at 12:47:44 UTC, Manu wrote:
>>>>>
>>>>> 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 ?
>>
>>
>> Surely it would map by file.
>>
>> #include <vector> -> import stl.vector;
>> #include <map> -> import stl.map;
>> #include <string> -> import stl.string;
>>
>> Perhaps 'stl' may be something else, 'std' is an unfortunate conflict with
>> phobos, but this is unique to this case.
>
>
> I believe deadalnix here meant something like this:
>
>   import stl.vector;
>   import mylib.vector;
>
>   Vector a; // Ambiguous: could be from mylib or stl
>   stl.Vector b; // Error: no such class stl.Vector
>   stl.vector.Vector c; // Works, but requires extra typing

Okay let me tweak your code:

   import stl.vector;
   import stl.string;   // one more thing; when do you ever only
import a single module?
   import mylib.vector;

   Vector a; // Ambiguous: could be from mylib or stl
   stl.Vector b; // Error: this wouldn't work, becase stl could be
stl.vector.stl or stl.map.stl
   stl.vector.Vector c; // This is what a D programmer expects,
exactly like every other conflict resolution in D ever, but it doesn't
work either

So, it is proposed that people desire to type only stl.Vector to
disambiguate, assuming that 'stl' is a named namespace.
This only works in the rare case that you only import one single
module. This is almost never true!
As soon as you import 2 modules, stl.vector, stl.string for instance,
'stl' is now in conflict, and you require to type:
  stl.vector.stl.Vector c; // Necessary, and even more extra typing!

I am yet to experience a single case of isolated imports... real code
that's not a 3 line test case tends to import more than one thing.
I also object strongly to the rules being different than every other
case of conflict in D that a user has ever experienced.


> Which with working namespaces might allow case b to work.

I hope I've shown how it almost never does, and only makes the situation worse.


More information about the Digitalmars-d mailing list