std.uni vs std.unicode and beyond?

[Jonathan M Davis]

On Thursday, May 23, 2013 09:15:22 Jacob Carlborg wrote:
> > So, the question is whether it's worth making people change their code
> > sometime between when we make the change and when std.uni finally goes
> > away. And I don't think that making people change their code is worth it
> > regardless of how gradual it is. std.uni is not as good a name as
> > std.unicode, but it's just not worth forcing people to change their code
> > in order to fix it. If we keep trying to tweak the names of modules and
> > functions and whatnot, we'll never be in a state where people can rely on
> > their code compiling across compiler versions. Tweaking some stuff is
> > necessary, and we did a lot in the past to fix symbol names, but we've
> > pretty much stopped doing that, and we have to draw the line somewhere.
> 
> How about drawing the line after we have gone through and cleaned up all
> modules that haven't gone through the review queue.

Even if we agreed that we wanted to do that, how is that realistically going 
to happen? Pretty much the only reason that as many of Phobos' names have been 
fixed as have been is because I took the time a couple of years ago to clean up 
a lot of the names so that they followed the naming conventions. Some changes 
were done by others, but the vast majority of it was me. If I hadn't taken the 
time to do that, it wouldn't have happened. And in all that time, no one else 
has taken the time to try and figure out what I missed and get that fixed. At 
best, some folks have fixed a few symbol names here and there. It's just not 
realistic to expect that we're going to be able to go through and fix every 
little naming detail in Phobos at this point. And as time passes, the cost of 
making the changes goes up, because the amount of code written using the old 
names increases. There was plenty of screaming about names being changed when 
I did it before. It would likely be even worse now, and the longer it took to 
actually find and fix every naming convention violation in Phobos, the more code 
which would be written using the old names and would break when we made the 
changes.

I tried to fix all of the naming problems in Phobos previously with the idea 
that we'd fix them all and then move on, and I got a large portion of them 
fixed, but I didn't get them all, and I think that it's past the time when it's 
reasonable to do so. There are too many people pushing for stability, and the 
lack of perceived stability is one of D's biggest detractors right now 
(regardless of what our actual level of stability is). Walter and Andrei in 
particular are of the opinion that the ROI on name changes at this point is 
too low for it to be worth it. Sure, aesthetically, it would be nice to fix 
them all, but at some point, we have to just move on and live with what we 
have. Fortunately, _most_ of it has been fixed already, and the biggest 
remaining offenders are modules that should probably be replaced wholesale 
anyway (e.g. std.socket), so they may get fixed if the ROI for replacing such 
modules is high enough (in which case, the fixing of names is a bonus which 
comes along with fixing something which actually _does_ have a ROI for changing 
it).

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.

- Jonathan M Davis