std.uni vs std.unicode and beyond?

Jonathan M Davis jmdavisProg at gmx.com
Thu May 23 03:21:05 PDT 2013


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


More information about the Digitalmars-d mailing list