Arbitrary abbreviations in phobos considered ridiculous

[Timon Gehr]

On 03/07/2012 11:30 PM, Jonathan M Davis wrote:
> On Wednesday, March 07, 2012 17:06:21 Nick Sabalausky wrote:
>> Ahh, yea I remember now. I'd argue (strongly) that if a symbol is
>> inaccessible than it should never conflict with a symbol that is accessible.
>> After all, is there really much more point to the "visible vs accessible"
>> distinction besides just being able to say "Symbol xxxx is private" instead
>> of "Unrecognzed symbol xxxx"?
>
> Well, truth be told, it should be possible for the compiler to still say that
> the symbol is private rather than that it's unrecognized. Just because it's
> hidden for overload resolution and the like doesn't mean that the compiler
> couldn't still recognize it as existing but inaccessible in cases where
> there's no other match. It _is_ probably easier to implement it with the
> "unrecognized symbol" behavior though.
>
> The only real downside that I can think of of making private symbols hidden is
> that it could cause issues when symbols are changed to or from private, but
> the way that overload sets are handled probably prevents that from being a
> real issue. It may break code, but I don't think that it would silently break
> code to change a symbol to or from private, which would be the real problem.
>
> - Jonathan M Davis

Yes, private symbols probably shouldn't be hidden completely. For 
example, private constructors convey special semantics. (their existence 
also removes the default constructor) But private symbols should never 
conflict with public symbols. Probably it is best to also disallow 
overloading private symbols against public symbols.