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

I think it is one of the most major problems with the whole module system right now...

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

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.

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

-- 
To err is human; to forgive is not our policy. -- Samuel Adler

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

There is a pull from Martin that implements new symbol access resolution rules and old DIP of mine on same topic. Those do contradict each other though as we seem to disagree on quite on rules related to template instances / alias arguments. Martin has the obvious benefit of actually having an implementation of course, I don't remember what is blocking its approval.

Everything related to alias template arguments is pretty much the main difficulty and discussion point when it comes to finally fixing this terribly annoying bug.