DIP22 : Private symbol visibility

[Dicebot]

On Wednesday, 30 January 2013 at 05:29:14 UTC, Jesse Phillips 
wrote:
> And this results in people writing code that ...? Is there an 
> example where you can break code in another module by changing 
> something marked as private?

Examples separated:
http://forum.dlang.org/post/irrbdrxordjawkryvrub@forum.dlang.org

> "There is currently no way in D to mark symbols for internal 
> linkage"
>
> What would that give us?

Strong 100% guarantees changes to the symbol won't break anything 
but its module. Strong 100% guarantees to compiler that he can 
optimize away/change all internal code when doing separate 
compilation.

> "Compiler errors upon access to private symbol are changed from 
> "%s is not accessible" to "undefined identifier %s""
>
> That will just be confusing. You put the name of that symbol 
> because you saw it, being told it is undefined is going to make 
> you think the compiler is broken.

That was the most uneasy part of proposal. I have been thinking 
for few hours about it, considering different options. In the 
end, I have decided that it is only confusing to one coming from 
C++ lax approach and for clean mind it should make perfect sense 
that private symbol is indistinguishable from non-existing one in 
regular user code - that is the point of encapsulation how I get 
it.

Also in case of denied access most likely you have put that 
symbol because of typo, not because you know it (why would you 
intentionally try to use symbol you already know is private?). 
And it exposes internal module details by an accident.

I am very open for more arguments though, it is a somewhat tricky 
change.