Path as an object in std.path

Walter Bright newshound2 at digitalmars.com
Thu Jun 6 10:37:27 PDT 2013


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.


More information about the Digitalmars-d mailing list