DIP22 : Private symbol visibility

[Dicebot]

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.