Conflict with private symbol from an imported module

[Paulo Pinto]

Am 23.01.2014 19:16, schrieb H. S. Teoh:
> On Thu, Jan 23, 2014 at 05:38:03PM +0000, Nicolas Sicard wrote:
>> On Thursday, 23 January 2014 at 17:29:08 UTC, Gary Willoughby wrote:
>>> On Thursday, 23 January 2014 at 17:06:17 UTC, Nicolas Sicard
>>> wrote:
>>>> Hi,
>>>>
>>>> I known this has been discussed before, and there still is an
>>>> open issue in bugzilla
>>>> (https://d.puremagic.com/issues/show_bug.cgi?id=1238). Is it
>>>> considered a feature or a bug?
>>>>
>>>> Thanks
>>>
>>> Modules are broken in several ways:
>>> https://d.puremagic.com/issues/show_bug.cgi?id=314
>>
>> It sure is broken. But I wondered if it would be let aside. I say
>> this because I think I remember reading (from Walter?) that it would
>> need a significant re-implementation to fix it.
>
> Reimplementation or not, I consider this a major bug. This has actually
> happened to me with Phobos:
>
> 1) In an earlier version of D, I had a module stack.d that declares a
> public symbol 'Stack', and another module mod.d that imports module
> stack and also std.regex.
>
> 2) In the meantime, Dmitri revised the implementation of std.regex and
> in the process introduced a *private* symbol Stack. These changes are
> merged into Phobos and included in the subsequent release.
>
> 3) I upgrade dmd to the subsequent release, and suddenly my code has a
> compile error, because the *public* symbol stack.Stack conflicts with
> the *private* symbol std.regex.Stack.
>
> Not only this is a major annoyance, it also breaks encapsulation because
> anytime you introduce new private symbols to your library module, you
> could, in theory, be breaking random user code due to these conflicts.
> Why should user code care that new *private* symbols were introduced to
> the module?? Such implementation details ought to be invisible to the
> outside world. Yet currently, user code has to disambiguate these
> conflicting symbols in order to compile.
>
> This travesty needs to be fixed, otherwise D will just remain a laughing
> stock of other languages.
>
>
> T
>


Fully agree.

- Private symbols should not be exposed

- It should be possible to distribute binary modules with the 
corresponding .di file.


--
Paulo