There was discussion recently about unpleasant name conflict possible with private module symbols. I have just encountered a sarcastically false statement on dlang.org : "Private module members are equivalent to static declarations in C programs."

Made me sad and wondering: was there any DIP after that thread or it has ended, as it often happens, with a decision to "plan carefully"? In latter case I may try to write one.

On Saturday, 26 January 2013 at 22:23:05 UTC, mist wrote:
> Made me sad and wondering: was there any DIP after that thread or it has ended, as it often happens, with a decision to "plan carefully"?

I *think* Walter is still against changing it, on the grounds that it would make module-level private different from any other type of private.

On Saturday, 26 January 2013 at 23:13:02 UTC, Peter Alexander wrote:
> I *think* Walter is still against changing it, on the grounds that it would make module-level private different from any other type of private.

Well, I thought it was an agreement that we exactly lack currently way to do C global static or C++ unnamed namespace behavior.

No opinion currently if this should be "private" or anything but statement from dlang.org I have cited is terribly wrong currently and something needs to be done about it.

On 1/26/13 6:13 PM, Peter Alexander wrote:
> On Saturday, 26 January 2013 at 22:23:05 UTC, mist wrote:
>> Made me sad and wondering: was there any DIP after that thread or it
>> has ended, as it often happens, with a decision to "plan carefully"?
>
> I *think* Walter is still against changing it, on the grounds that it
> would make module-level private different from any other type of private.

Walter and I believe it is necessary to define module private in a way that makes the symbol impossible to leak. Work on a detailed DIP would be definitely welcome. Walter enumerated a few concerns that the DIP should address in a message. What was the title of the past discussion?

Andrei

On Saturday, 26 January 2013 at 22:23:05 UTC, mist wrote:
> There was discussion recently about unpleasant name conflict possible with private module symbols. I have just encountered a sarcastically false statement on dlang.org : "Private module members are equivalent to static declarations in C programs."
>
> Made me sad and wondering: was there any DIP after that thread or it has ended, as it often happens, with a decision to "plan carefully"? In latter case I may try to write one.

Can you explain what is broken ?

On 01/27/2013 01:25 PM, Andrei Alexandrescu wrote:
> On 1/26/13 6:13 PM, Peter Alexander wrote:
>> On Saturday, 26 January 2013 at 22:23:05 UTC, mist wrote:
>>> Made me sad and wondering: was there any DIP after that thread or it
>>> has ended, as it often happens, with a decision to "plan carefully"?
>>
>> I *think* Walter is still against changing it, on the grounds that it
>> would make module-level private different from any other type of private.
>
> Walter and I believe it is necessary to define module private in a way
> that makes the symbol impossible to leak. Work on a detailed DIP would
> be definitely welcome. Walter enumerated a few concerns that the DIP
> should address in a message. What was the title of the past discussion?
>
> Andrei

http://forum.dlang.org/post/kb86il$1u9v$1@digitalmars.com

Most annoying for me:

$ cat mod1.d
module mod1;

private void func(int) { }

$ cat mod2.d
import mod1;

void main() { func(42); }

$ rdmd mod2.d
mod2.d(3): Error: module mod2 mod1.func is private
mod2.d(3): Error: function mod1.func is not accessible from module mod2

With static in C and unnamed namespace in C++ those symbols do not participate in outer name resolution at all and do not exist as symbols in resulting object file.

Probably there are others, more subtle issues. I'll need to re-parse all discussion in that topic if going to try do a DIP about it.

As no one seems to be working on this I may try to resurrect all the info from previous topic and combine into a DIP matching Walters request. Added this to personal TODO list.

Thanks.

On 1/27/13 8:27 AM, Timon Gehr wrote:
> On 01/27/2013 01:25 PM, Andrei Alexandrescu wrote:
>> On 1/26/13 6:13 PM, Peter Alexander wrote:
>>> On Saturday, 26 January 2013 at 22:23:05 UTC, mist wrote:
>>>> Made me sad and wondering: was there any DIP after that thread or it
>>>> has ended, as it often happens, with a decision to "plan carefully"?
>>>
>>> I *think* Walter is still against changing it, on the grounds that it
>>> would make module-level private different from any other type of
>>> private.
>>
>> Walter and I believe it is necessary to define module private in a way
>> that makes the symbol impossible to leak. Work on a detailed DIP would
>> be definitely welcome. Walter enumerated a few concerns that the DIP
>> should address in a message. What was the title of the past discussion?
>>
>> Andrei
>
> http://forum.dlang.org/post/kb86il$1u9v$1@digitalmars.com

Thanks. That's the one! Looking forward to seeing a DIP.

Andrei

On 1/27/13 8:58 AM, Dicebot wrote:
> Most annoying for me:
>
> $ cat mod1.d
> module mod1;
>
> private void func(int) { }
>
> $ cat mod2.d
> import mod1;
>
> void main() { func(42); }
>
> $ rdmd mod2.d
> mod2.d(3): Error: module mod2 mod1.func is private
> mod2.d(3): Error: function mod1.func is not accessible from module mod2
>
> With static in C and unnamed namespace in C++ those symbols do not
> participate in outer name resolution at all and do not exist as symbols
> in resulting object file.
>
> Probably there are others, more subtle issues. I'll need to re-parse all
> discussion in that topic if going to try do a DIP about it.

I agree that mod1.func should not even be visible from mod2.

Andrei