-
-
Notifications
You must be signed in to change notification settings - Fork 704
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove usages of 'dur' #485
Conversation
|
@jmdavis what do you think? |
|
As I explained in the associated druntime pull request, I'm against the idea. A number of people seem to like the idea of having non-generic functions such as However, I'm definitely against renaming I haven't closed this pull request or the druntime one, because I've been waiting to see if Nick would remove the changes to |
|
As (more or less) indicated in the inital comment, this pull request is alias dur!"minutes" minutes; Etc. If those aliases are added, then this merely updates phobos to use those As he states in that pull request (druntime #174) , Jonathan is strongly If the idea of "dur -> duration" is completely dead, but the aliases are (I hope that's not too rambling to make sence...) |
|
"However, I'm definitely against renaming dur to duration. It wasn't duration in the first place, because then it gets too long when you call it (e.g. duration!"hours"(5) or duration!"seconds"2")), so while the name dur is a bit ugly, it's the best abbreviation that I could come up with, and I think that the function name needs to be abbreviated to avoid being too long - particularly in complicated expressions. On top of that, changing it to duration would break code. We've been trying to reduce code breakage, and I don't think that renaming dur to duration is worth the breakage that it would cause." My reasoning for "dur->duration" was that the "minutes"/"hours"/etc aliases would be even shorter still and would eliminate 90+% of direct uses of "dur". Therefore, the motivation for a shortened version of "dur" would be strongly mitigated, thus enabling us to go with the more readable (and more popular from what I can tell) "duration". Now, if "dur -> duration" is completely vetoed (I don't know how these processes work), then I won't push on that point anymore and druntime #174 cn be closed. In that case, the question becomes "Ok, now what about the aliases?" Personally, I think the possible issues with name conflicts, at least in these cases, are much more trivial and uncommon than jmdavis feels that they are. FWIW, many people on the NG seemed to be very much in favor of the aliases. |
|
@brad Anderson: Yea. I'd been holding off on that out of hope that the |
|
@ALL: With all this talk about "aliases", I do realize standard phobos style |
|
@Abscissa Yes, I don't like But regardless of whether we introduce |
|
Ehm if all these hours, seconds etc. were @Property function helpers, then we'd have amazingly nice syntax: Changing dur --> duration is going to break code for no real value, so is a no go, IMHO. |
The exact same thing was being argued with std.log and some of its choices in function names. |
|
The fact that we are arguing about it to me indicates one of two things: I'm still of the opinion it's more of b, then a. But indeed there are issues with modules, tons of them. |
|
Even if we add the wrappers for |
This goes with dlang/druntime#174