"Jonathan M Davis" <jmdavisp...@gmx.com> wrote in message news:mailman.366.1331335812.4860.digitalmar...@puremagic.com... > On Friday, March 09, 2012 16:16:56 Brad Anderson wrote: >> On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis >> <jmdavisp...@gmx.com>wrote: >> > On Friday, March 09, 2012 17:41:01 Steven Schveighoffer wrote: >> > > 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. >> > >> > aliases need to have a really good argument for existing. If UFCS is >> > fully >> > implemented, then I think that there is _some_ argument for having >> > stuff >> > like >> > hours and minutes, because then you can do stuff like 5.seconds() >> > (though >> > honestly, I really don't like the idea). The alias enables different >> > usages >> > rather than simply being another name for the same thing. >> > >> > Now, in this particular case, it's that much worse for exactly the >> > reason >> > that >> > you're against it: it uses common names for free functions. It's not as >> > big a >> > problem as it would be in C or C++, but it's still a problem. There's >> > also >> > some risk that it will break code. >> >> Oh, and I'd just like to add some of my experience to this. These names >> are >> used by Boost's datetime library and they've never been a problem for me >> and at work we make extensive use of Boost datetime. There is risk but I >> think in this specific case they are fairly small (especially in D, over >> C++). We switched to Boost datetime after we had hundreds of thousands of >> lines of code written using a different system and I didn't encounter any >> problems with the duration shortcut functions clashing. >> >> Anyway, it sounds like Walter is probably opposed from what he was saying >> in the other thread so this conversation is probably moot. > > I'd say that there's a higher chance of the aliases being added than of > dur > being changed to duration. Changing dur will _definitely_ break code and > make > using it worse for exactly the same reason that it's dur in the first > place - > it's too long when combined with the required units string. The aliases > might > break code, but it's probably only in cases where someone already has free > functions with those names, and it's more likely that they'll have > variables > with those names, which are less likely to conflict. > > So, while I don't really like the idea of adding the aliases, they _might_ > be > added, because they probably won't break anything, and they enable UFCS. > But > there's not a good enough reason to change dur to duration at this point. >
They eliminate the *entire* reason for it ever even being "dur" in the first place. Of course, if this incarnation of std.datetime were a few years old, then I'd likely agree with you, but it *is* still relatively new.