Arbitrary abbreviations in phobos considered ridiculous

Martin Nowak dawg at dawgfoto.de
Wed Mar 7 18:40:17 PST 2012


On Thu, 08 Mar 2012 01:00:48 +0100, Timon Gehr <timon.gehr at 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


More information about the Digitalmars-d mailing list