On Thu, 08 Mar 2012 01:00:48 +0100, Timon Gehr <timon.g...@gmx.ch> wrote:
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.
Private symbols can be proposed during the spell correction lookup.
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.
It doesn't work out if you want to overload private/public constructors.
https://github.com/D-Programming-Language/dmd/pull/739
