Arbitrary abbreviations in phobos considered ridiculous

[Steven Schveighoffer]

On Fri, 09 Mar 2012 16:47:01 -0500, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Friday, March 09, 2012 16:36:27 Steven Schveighoffer wrote:
>> On Fri, 09 Mar 2012 16:14:08 -0500, Nick Sabalausky <a at a.a> wrote:
>> > "Nick Sabalausky" <a at a.a> wrote in message
>> > news:jj6gjm$2m6a$1 at digitalmars.com...
>> >
>> >> But, I'm thinking this whole "dur vs duration" matter is stupid  
>> anyway.
>> >> Seconds, hours, etc *are* durations. What the hell do we even need  
>> the
>> >> "dur" or "duration" for anyway?
>> >>
>> >> I say fuck it: Let's just toss this into core.time (or std.datetime  
>> or
>> >> whatever) and be done:
>> >>
>> >> alias dur!"years" years;
>> >> alias dur!"months" months;
>> >> alias dur!"weeks" weeks;
>> >> alias dur!"days" days;
>> >> alias dur!"hours" hours;
>> >> alias dur!"minutes" minutes;
>> >> alias dur!"seconds" seconds;
>> >> alias dur!"msecs" msecs;
>> >> alias dur!"usecs" usecs;
>> >> alias dur!"hnsecs" hnsecs;
>> >>
>> >> And then we have the brevity issue solved (and in fact, improved over
>> >> "dur"), so then "dur" can (and should) change to "duration" without
>> >> screwing up brevity. And all probelms are optimally solved. As for  
>> the
>> >> possibility of new name collisions: Honestly, in this case I see no
>> >> reason
>> >> to give a shit.
>> >
>> > https://github.com/D-Programming-Language/druntime/pull/174
>> >
>> > https://github.com/D-Programming-Language/phobos/pull/485
>> >
>> > https://github.com/D-Programming-Language/tools/pull/23
>> >
>> > I completely understand the "secs==seconds" pull request being  
>> rejected
>> > and
>> > I think that's perfectly reasonable...
>> >
>> > But I'm going to be really pissed if this one's rejected out of some
>> > misapplied, overly-puritanical obsession with "no aliases".
>>
>> You'll need to have dur aliased to duration to follow the normal
>> deprecation procedure.
>>
>> I can't say I agree with this, as it pollutes the global namespace with
>> several common terms that could be used for fields.
>
> Yeah. My general reaction is that this is a _bad_ idea. It creates  
> aliases and
> uses names for free functions which are commonly used. We'll see if  
> Walter says
> anything about this one, but my first reaction is to reject it. I'll  
> wait for
> comments on it though.

I'll say I *don't* agree with the rejection of aliases on principle --  
aliases can be extremely useful/helpful, and they cost literally nothing  
(the "cognitive cost" on the docs is a BS argument IMO).  I just don't  
agree with consuming so many common symbols for the sake of sugar.

-Steve