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