Arbitrary abbreviations in phobos considered ridiculous

[Timon Gehr]

On 03/07/2012 10:47 PM, Jonathan M Davis wrote:
> 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:
>>>>> On Tuesday, March 06, 2012 19:35:29 Andrei Alexandrescu wrote:
>>>>>> In fact there is no such thing as a top level in D. (I was quite
>>>>>> surprised to learn that a few years ago, and found it quite
>>>>>> brilliant of Walter.)
>>>>>
>>>>> 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. It's just like how
> private functions can affect function overloading in spite of the fact that
> other modules can't use them.
>
> This completely follows how private is designed. So, it's not a bug. But there
> are definitely arguments for changing how private works (e.g. the fact that you
> can't really alias stuff within a module without affecting other modules). The
> trick is convincing Walter to change it.
>
> - Jonathan M Davis

There is absolutely no remotely valid argument against changing the 
behavior that does not involve a discussion of the compiler internals.