Dawid Ciężarkiewicz wrote:
> The good error msg would look like:
> 
> $file($line): triggered import conflict with X ($X:$Xline) and Y
> ($Y:$Yline)
> 
> Where $file($line) is place where compiler found that this two modules are conflicting. This would be quite informative IMO.

Yes.

> 
> Another thing is that I do "private import $i" for purpose - I don't want names from module be _anyhow_ visible - not triggering any conflicts.

I think they should be visible enough to trigger a proper error message, when you don't have any public symbols with the same name. But when you do have, the compiler should be able to mask the private ones then. Only if you have at least two public symbols with the same name, a name conflict should appear.

-- 
Jari-Matti

Jari-Matti Mäkelä wrote:
> Deewiant wrote:
>> I have long felt that private [import] should be the default.
> 
> Yes. But imports should work properly, too.
> 

Quite correct.

<rant>
Hell, "private" should work properly! As Sean Kelly posted to this thread, C++
has its (arguable) reasons for why "private members are inaccessible but not
invisible", but D doesn't (seem to) have any. It's quite an annoyance, if not worse.
</rant>

You're write it is awful.  A useful error message would make this a hundred times easier.

I've also noticed this always happens strictly with phobos, has anyone had these conflicts with their own modules ?


In article <e71f1s$31fj$1@digitaldaemon.com>, Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= says...
>
>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)
>
>GAME OVER!
>
>You're stuck with this nothing telling you error message. You start wondering what is wrong. Imports probably, but ... why? It takes 15 minutes of frustrating checking your files. You seek help on #D irc channel (nice people BTW) - but they can not help you. They can only tell "It might be that in some unrelated file you are trying to use map without importing map but are importing files that do import map" which is great help but still will require you to spend great amount of time finding this place.
>
>Please Walter - fix this. It is sooooooo frustrating and everyone confirms that. It's something that all D people hits once or more.

I hear ya wrote:
> You're write it is awful.  A useful error message would make this a hundred
> times easier.
> 
> I've also noticed this always happens strictly with phobos, has anyone had these
> conflicts with their own modules ?

Ummmm yeah... a lot...

Walter, please fix it, it will save my hair ;D


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

On Sun, 18 Jun 2006 04:15:11 +1000, Chris Miller <chris@dprogramming.com> wrote:

> DMD 0.160:
>     foo.d(1): import foo.std conflicts with bar.std at bar.d(1)
>
>
> Of course, the code in test.d is a mistake, but look how unhelpful the error message is. It will blame a library's code for a mistake the library-user made.

Maybe a message more like ...

    foo.d(6): std.string is not accessible

might be more useful for coders.

> Also notice that it's considering *private* imports, which shouldn't even be available to test.d.

This has been broken for a *long* time now. Both "private" and "package" are just ignored by DMD for at least the last 5 or 6 releases. It used to work but now it doesn't.

-- 
Derek Parnell
Melbourne, Australia

On Sun, 18 Jun 2006 04:30:32 +1000, Sean Kelly <sean@f4.ca> wrote:

> Derek Parnell wrote:
>>  I have yet to find a *need* for public imports.
>
> I have.  Implementing C headers it's common for an alias to be declared in one header that must be visible in other headers.  Sure, you could require the user to manually import both headers, but that's non-intuitive and a tad annoying.  And the alternative (private import combined with aliasing symbols to expose them piecemeal) results in symbol collision problems.

And yet I find it intuitive and helpful. People differ.

For me, if 'foo' is declared in A, and B needs to access 'foo' then B should import A. Now if C needs to access something in B and access 'foo' it should import both A and B. This seems natural to me. To do otherwise means that C's access to 'A.foo' becomes dependant on the implementation of B. This is too much cohesion in my books.

And yes, it can result in the need to disambiguate public symbol references in C, but I see that as a good thing. It help document the code and reduces the chance of calling the wrong function.

-- 
Derek Parnell
Melbourne, Australia

Derek Parnell wrote:
> 
>> Also notice that it's considering *private* imports, which shouldn't even be available to test.d.
> 
> This has been broken for a *long* time now. Both "private" and "package" are just ignored by DMD for at least the last 5 or 6 releases. It used to work but now it doesn't.
> 
> --Derek Parnell
> Melbourne, Australia

5 or 6 releases? Far more than that, this bug (http://d.puremagic.com/bugzilla/show_bug.cgi?id=48) was reported for DMD .149 and it was broken I don't know how many releases even before that.
You said it used to work? When?

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

On Sun, 18 Jun 2006 10:58:27 +1000, Bruno Medeiros <brunodomedeirosATgmail@SPAM.com> wrote:

> Derek Parnell wrote:
>>
>>> Also notice that it's considering *private* imports, which shouldn't even be available to test.d.
>>  This has been broken for a *long* time now. Both "private" and "package" are just ignored by DMD for at least the last 5 or 6 releases. It used to work but now it doesn't.
>>  --Derek Parnell
>> Melbourne, Australia
>
> 5 or 6 releases? Far more than that, this bug (http://d.puremagic.com/bugzilla/show_bug.cgi?id=48) was reported for DMD .149 and it was broken I don't know how many releases even before that.

I was being generous and polite ;-)

> You said it used to work? When?

The 'private' used to work at one stage because I tripped up on it. What one has to remember is that private restricts access but not visiblity. The 'package' qualifier has never worked AFAIK.



-- 
Derek Parnell
Melbourne, Australia

Sean Kelly wrote:
> 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 can't figure out what kind of parallel or comparison could be made of symbol resolution with a language that has no structured module system. What would be the analogous case in C++ for the situation mentioned above? What are the C++ class-scope rules?

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Derek Parnell wrote:
> On Sun, 18 Jun 2006 04:15:11 +1000, Chris Miller <chris@dprogramming.com>  wrote:
> 
>> DMD 0.160:
>>     foo.d(1): import foo.std conflicts with bar.std at bar.d(1)
>>
>>
>> Of course, the code in test.d is a mistake, but look how unhelpful the  error message is. It will blame a library's code for a mistake the  library-user made.
> 
> 
> Maybe a message more like ...
> 
>     foo.d(6): std.string is not accessible
> 
> might be more useful for coders.
> 
>> Also notice that it's considering *private* imports, which shouldn't  even be available to test.d.
> 
> 
> This has been broken for a *long* time now. Both "private" and "package"  are just ignored by DMD for at least the last 5 or 6 releases. It used to  work but now it doesn't.

How is anyone new to D supposed to even consider using it when stuff like _private_ and _package_ are broken????????????????????????

This is both *elementary* and *essential* to any nontrivial project. It simply *has* to work.

"Would you buy a 3-wheel Ferrari?"

The first guys we lose this way are those who were considering D for real work (as opposed to hobby or tinkering).