On 6/6/2013 9:50 AM, Dylan Knutson wrote:
Well, it comes down to are we willing to marginally break code for the sake of a
better API. 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 don't believe that because we broke A, therefore it's ok to break B.
And secondly, it isn't clear that Path is a better API.
I'm not opposed to breakage in all cases. But there needs to be a big win to
justify it. I'm not seeing even a small net win for Path types. I'm not talking
hypothetical either, like I said, I've tried them several times.
> Projects such as Dub, Vibe, and to an extent Tango disagree.
I agree there's a strong temptation to create a Path object, and I've succumbed
myself to it several times. A corollary is that people often wanted to create a
String class, too, though that has died out.
You might also consider David Nadlinger's counter example:
"As another data point (which may or may not be relevant for the discussion
here), the LLVM system/support library was initially based on Path objects, but
recently has been rewritten to use raw strings:
http://llvm.org/docs/doxygen/html/namespacellvm_1_1sys_1_1path.html";
I've rewritten my Path code to go back to raw strings, too.
