On Thursday, June 06, 2013 13:45:44 Andrei Alexandrescu wrote: > > D and Phobos aren't considered stable by any > > standard; I don't think we should treat them like they're set in stone. > > Also, deprecation gives developers plenty of time to update their code > > (if they have to at all). > > I think this opinion is very unlikely to enjoy popularity. We actively > /want/ to make Phobos more stable, so using the argument that it's not > yet stable to add more instability is sure to fit the pattern of some > list of fallacies. Besides, the corresponding benefits (the best solid > argument that could be constructed) are at least according to some not > that large to justify the cost of breakage.
Agreed. Breaking stuff in an effort to create a solid, stable API is one thing (and at this point, we want to minimize even that as much as we reasonably can). Constantly going back and rebreaking stuff is quite another. We already redid std.path. It went through the full review process and was voted in. We want to move towards being _more_ stable not less. Some API breakage will still be necessary (like replacing std.xml or the streaming modules), but it's a cost that we want to avoid when it isn't necessary. Each module redesign must justify itself, and the simple fact that other modules have already been redesigned is not enough for that. Not to mention, over time, it should arguably require _more_ justification to redo a module (or make any breaking change in Phobos), because more people are using it, and we really do want to be stable. - Jonathan M Davis
