http://wiki.dlang.org/DIP22

There are two important issues with current protection attribute
design:

* Senseless name clashes between private and public symbols
* No way to specify internal linkage storage class

This DIP addresses both of them with two decoupled proposals:

* Change of private related name resolution rules
* Definition of static storage class for module-scope symbols.

___________________________________________

Quotes, data and link to previous discussion:
http://wiki.dlang.org/Access_specifiers_and_visibility

___________________________________________

I think this is the point where public discussion will do more
good than my own exploration of corner cases. Please destroy and
pay closest attention to compile-time reflection - I have a
feeling I have missed something there.

On Monday, 28 January 2013 at 17:05:38 UTC, Dicebot wrote:
> http://wiki.dlang.org/DIP22

Error on that page (for C++):

" public
Default one, "if you can see symbol - you can access it"

That is true only for structs. For classes, "private" is the default.

See also this:

http://stackoverflow.com/questions/1247745/default-visibility-of-c-class-struct-members

On Monday, 28 January 2013 at 17:18:27 UTC, eles wrote:
> On Monday, 28 January 2013 at 17:05:38 UTC, Dicebot wrote:
>> http://wiki.dlang.org/DIP22
>
> Error on that page (for C++):
>
> " public
> Default one, "if you can see symbol - you can access it"
>
> That is true only for structs. For classes, "private" is the default.
>
> See also this:
>
> http://stackoverflow.com/questions/1247745/default-visibility-of-c-class-struct-members

It was on http://wiki.dlang.org/Access_specifiers_and_visibility actually, I had global symbols in mind when was writing that. Fixed now.

On 01/28/2013 06:05 PM, Dicebot wrote:
> http://wiki.dlang.org/DIP22
>
> There are two important issues with current protection attribute
> design:
>
> * Senseless name clashes between private and public symbols
> * No way to specify internal linkage storage class
>
> This DIP addresses both of them with two decoupled proposals:
>
> * Change of private related name resolution rules
> * Definition of static storage class for module-scope symbols.
>
> ___________________________________________
>
> Quotes, data and link to previous discussion:
> http://wiki.dlang.org/Access_specifiers_and_visibility
>
> ___________________________________________
>
> I think this is the point where public discussion will do more
> good than my own exploration of corner cases. Please destroy and
> pay closest attention to compile-time reflection - I have a
> feeling I have missed something there.

Fixing private is enough.

Not a fan of the static thing at all. It is a great thing that the static attribute actually has a consistent meaning in D.

mixin template X(){
    static int x = 2;
}

class C{
    mixin X; // x is a public TLS variable
}

mixin X; // x is a public TLS variable.

No need to screw this up.

On Monday, 28 January 2013 at 17:36:58 UTC, Timon Gehr wrote:

> Fixing private is enough.
>
> Not a fan of the static thing at all. It is a great thing that the static attribute actually has a consistent meaning in D.
>
> mixin template X(){
>     static int x = 2;
> }
>
> class C{
>     mixin X; // x is a public TLS variable
> }
>
> mixin X; // x is a public TLS variable.
>
> No need to screw this up.

Good, that was exactly example I could not crystallize. I wanted to avoid introduction of new keyword, thus reused static. May be there is no such way around.

Anyway, I intentionally kept static and private parts decoupled so either of them can be approved alone.

On 2013-01-28 18:05, Dicebot wrote:
> http://wiki.dlang.org/DIP22
>
> There are two important issues with current protection attribute
> design:
>
> * Senseless name clashes between private and public symbols
> * No way to specify internal linkage storage class
>
> This DIP addresses both of them with two decoupled proposals:
>
> * Change of private related name resolution rules
> * Definition of static storage class for module-scope symbols.
>
> ___________________________________________
>
> Quotes, data and link to previous discussion:
> http://wiki.dlang.org/Access_specifiers_and_visibility
>
> ___________________________________________
>
> I think this is the point where public discussion will do more
> good than my own exploration of corner cases. Please destroy and
> pay closest attention to compile-time reflection - I have a
> feeling I have missed something there.

I think it looks good. What's not mentioned is ".tupleof", see:

http://forum.dlang.org/thread/llizpsrachdtqtshppud@forum.dlang.org?page=2#post-ke6lv8:242nn8:241:40digitalmars.com

-- 
/Jacob Carlborg

> Fixing private is enough.
>
> ...
>
> No need to screw this up.

By the way, do you oppose exactly "static" keyword usage or ability to mark symbols for internal linkage at all? How about something like @internal?

On 01/29/2013 11:29 AM, Dicebot wrote:
>> Fixing private is enough.
>>
>> ...
>>
>> No need to screw this up.
>
> By the way, do you oppose exactly "static" keyword usage> or ability to
> mark symbols for internal linkage at all? How about something like
> @internal?

I only oppose changing the meaning of "static". I do not have any strong feelings about being able to mark symbols for internal linkage, but I do not see why it is necessary. Can't a compiler just mark all symbols for internal linkage that can be marked such given the constraints you would impose on @internal marked symbols?

On Tuesday, 29 January 2013 at 16:44:56 UTC, Timon Gehr wrote:
> On 01/29/2013 11:29 AM, Dicebot wrote:
>>> Fixing private is enough.
>>>
>>> ...
>>>
>>> No need to screw this up.
>>
>> By the way, do you oppose exactly "static" keyword usage> or ability to
>> mark symbols for internal linkage at all? How about something like
>> @internal?
>
> I only oppose changing the meaning of "static". I do not have any strong feelings about being able to mark symbols for internal linkage, but I do not see why it is necessary. Can't a compiler just mark all symbols for internal linkage that can be marked such given the constraints you would impose on @internal marked symbols?

As far as I can see, it is rather problematic. When compiling module compiler may never know what will be referenced from other object files during link time. Even private symbols that do not leak can't be removed away that simple - we really want to preserve ability to access private members via tupleof and/or traits for power libraries. And it is nice to have compiler support to verify symbols does not leak ( == you can change/remove it any time with 100% guarantees to break no other module ) as an additional cherry on top.

On Tuesday, 29 January 2013 at 16:44:56 UTC, Timon Gehr wrote:
> On 01/29/2013 11:29 AM, Dicebot wrote:
>>> Fixing private is enough.
>>>
>>> ...
>>>
>>> No need to screw this up.
>>
>> By the way, do you oppose exactly "static" keyword usage> or ability to
>> mark symbols for internal linkage at all? How about something like
>> @internal?
>
> I only oppose changing the meaning of "static". I do not have any strong feelings about being able to mark symbols for internal linkage, but I do not see why it is necessary. Can't a compiler just mark all symbols for internal linkage that can be marked such given the constraints you would impose on @internal marked symbols?

I have to support that.

static have already quite a lot of different meaning in D, and adding yet a new one probably not a good idea. Especially when module level declaration are supposed to be static by default, so now they can be static static, which is clearly a bad idea.

Is the usage of export have been considered here ? private declaration are static/private, unless defined export ? Does that work ?