On 2013-05-23 05:15, Jonathan M Davis wrote:
Every time that a library change is introduced it's done in a way that allows the programmer time to migrate their code. I'm not aware of any case thus far where we've purposefully changed library code in a manner which immediately broke user code. We don't even do that with the compiler. The problem is all of the times that it happens on accident (particularly with compiler regressions). So, regardless, we're not going to immediately break code out from under people.
Surprise, surprise. This just happened for me today. There were static methods in DWT marked as "shared". This doesn't compile with the latest beta (2.063 5). No warnings, no deprecation message, just suddenly stopped compiling.
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.
-- /Jacob Carlborg
