DIP22 : Private symbol visibility

[Dicebot]

On Thursday, 31 January 2013 at 14:50:05 UTC, Jonathan M Davis 
wrote:
> I see no point to the internal linkage stuff. What we need is 
> for inaccessible
> symbols to not be put in overload sets. I'm not sure that it 
> really needs to
> be any more complicated than that.
>
> - Jonathan M Davis

I predicted there will be some tension about internal linkage 
stuff and mostly decoupled it from private stuff so that it can 
be easily separated into another DIP and implemented in case 
other part is rejected.

Still, no need for internal linkage is felt because D projects 
are very small nowadays and does not involve complex separate 
compilation systems and\or large teams of programmers working on 
a single project. What internal linkage gives you is hard 100% 
guarantee (verified by the compiler) that this piece of code may 
be changed as you wish and it won't affect anything but this 
module. Private can't give such guarantees without code breakage. 
It is a widely used idiom in C/C++ that D currently has no 
replacement.