View mode: basic / threaded / horizontal-split · Log in · Help
January 26, 2013
Fixing module-scope private
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.
January 26, 2013
Re: Fixing module-scope private
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.
January 26, 2013
Re: Fixing module-scope 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.
January 27, 2013
Re: Fixing module-scope private
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
January 27, 2013
Re: Fixing module-scope private
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 ?
January 27, 2013
Re: Fixing module-scope private
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
January 27, 2013
Re: Fixing module-scope private
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.
January 27, 2013
Re: Fixing module-scope private
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.
January 27, 2013
Re: Fixing module-scope private
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
January 27, 2013
Re: Fixing module-scope private
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
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home