[frustration, sorry] Import conflict madness.

[Sean Kelly]

Dawid Ciężarkiewicz wrote:
> You write your great soft in D. You're coding with smile because everything
> in seems to be so good. You added few new files, new classes. Porting your
> project from C++ to D seems to be so good idea. You type "make".
> 
> And then out of nowhere: BANG!!!
> 
> battle.d(31): import battle.map conflicts with cell.cell.map at
> cell/cell.d(29)

For what it's worth, the symbol resolution rules styled after the C++ 
class-scope rules.  On the surface, this does seem to provide solid 
support for the approach: it's a sticky issue and an established 
language has solved the problem this way, so why not do that?  However, 
I think the reasons that this rule was chosen for C++ may be related to 
language syntax that D simply doesn't have, thus reducing the strength 
of the correlation.

I decided to go looking for information on why the C++ rules are the way 
they are, and oddly enough the first hit was the C++ Module proposal 
(available here: 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1964.pdf) 
Section 4.3 reads thus:

   4.3 Shielding from private members

   The fact that private members are inaccessible but not invisible
   regularly surprises incidental programmers. Like macros, seemingly
   unrelated declarations interfere with subsequent code. Unfortunately,
   there are good reasons for this state of affair: Without it, private
   out-of-class member declarations become impractical to parse in the
   general case.

   Module namespaces appear to be an ideal boundary for making the
   private member fully invisible: Within the module the implementer has
   full control over naming conventions and can therefore easily avoid
   interference, while outside the module the client will never
   have to implement private members. (Note that this also addresses the
   concerns of N1602 "Class Scope Using Declarations & private Members"
   by Francis Glassborow; the extension proposed therein is then no
   longer needed.)

It's worth noting that the issue discussed in the first paragraph: 
out-of-class declarations, is not supported in D.  All members must be 
declared in class scope.  The second paragraph goes on to make an 
argument for why private symbols should not be considered across modules 
for lookup resolution.  The only issue not addressed is package 
visibility, but I believe the same approach could be done at the package 
level as at the module level.  After all, there's a file separation 
either way.

I was unable to find older discussions relating why these rules were 
chosen for C++, but if there are other arguments against the approach 
which apply to D, either for current or future features, I would love to 
hear them.  The current state of affairs is annoying and somewhat 
confusing to new users, but I'd prefer an annoying system that works for 
all corner-cases to a cleaner one that doesn't.


Sean