DIP22 : Private symbol visibility

Timon Gehr timon.gehr at gmx.ch
Mon Jan 28 09:36:57 PST 2013


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.


More information about the Digitalmars-d-announce mailing list