On Thursday, May 23, 2013 11:10:04 Jacob Carlborg wrote: > On 2013-05-23 10:49, Jonathan M Davis wrote: > > I understand why people want changes like this (and to some extent, I > > agree), but I think that if they really wanted them, they should have > > pushed for them and created pull requests for them long before now. > > I don't see how a pull request will help. The problem is that none of > the developers that have push/merge permissions want to change the > names.
We did it before for quite a few functions, but Andrei and Walter are very much against it now. Merging changes like that at this point would likely incur their wrath. But we've had years where they could have been fixed, and 90+% of the changes were done by me. Other people made some name changes as well, and they got merged, but very few people who were pushing for name changes ever went and actually submitted pull requests for them. Previously, they would have been merged, but not now. > Would you merge a pull request that changed "dur" to "duration" > in std.datetime? Definitely not. But I wouldn't have changed that even if Walter and Andrei thought that we should go through the entirety of Phobos and clean up all of the names no matter how much code broke. While dur is not a great name, duration is too long when coupled with the template arguments (which is why it got shortened in the first place). I was between a rock and a hard place on that one, and I decided that it was more useable in this case to go with the shorter name, even if it wasn't ideal. Clearly, you don't agree, but we now have minutes, seconds, etc. as aliases if you don't like dur. If Andrei and Walter weren't so against making name changes at this point, I probably would merge pull requests with name fixes that I agreed with (I certainly would have a year or two ago), but increasingly, I agree with them that we need to stop doing that. It's just taken too long to sort that out, and we need to work on making sure that the compiler and standard library are stable more than we need to sort out some aesthetic fixes for APIs and the like, as nice as it would be to have those fixes. And no, we're not completely stable yet, but unless we try to restrict breaking changes to places with a high ROI, we never will be stable. - Jonathan M Davis
