Arbitrary abbreviations in phobos considered ridiculous

[Nick Sabalausky]

"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.186.1331156894.4860.digitalmars-d at puremagic.com...
> On Wednesday, March 07, 2012 15:34:44 Nick Sabalausky wrote:
>> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
>> news:mailman.180.1331149159.4860.digitalmars-d at puremagic.com...
>>
>> > On Tuesday, March 06, 2012 21:56:38 H. S. Teoh wrote:
>> >> On Tue, Mar 06, 2012 at 07:48:37PM -0800, Jonathan M Davis wrote:
>> >> >
>> >> > True, but if names conflict, you then have to worry about using the
>> >> > full import paths for symbols, which can get annoying.
>> >>
>> >> [...]
>> >>
>> >> I thought that's what module aliases were for.
>> >
>> > They can help, but thanks to the fact that they impact any other 
>> > modules
>> > that
>> > import that module, they're often unacceptable.
>>
>> That's just an implementation bug, though, isn't it? And wasn't it 
>> recently
>> fixed?
>
> It's a design issue. Yes, the bug that private didn't affect aliases was 
> fixed,
> but private does _not_ hide symbols. It only makes them inaccessible. So, 
> for
> instance, if std.datetime were to alias std.string.indexOf to indexOf, 
> then
> every module which imports both std.algorithm and std.datetime would then 
> have
> to either alias std.algorithm.indexOf themselves or use the full import 
> path.
> So, as it stands, private aliases are pretty much useless.

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"?