On Thursday, October 03, 2013 22:57:22 Craig Dillabaugh wrote: > On Thursday, 3 October 2013 at 19:49:07 UTC, Jonathan M Davis > > wrote: > > On Thursday, October 03, 2013 20:57:20 Craig Dillabaugh wrote: > >> On Thursday, 3 October 2013 at 18:12:01 UTC, Jonathan M Davis > > clip > > >> > - Jonathan M Davis > >> > >> Fair enough. As you point out the fix is pretty simple. > >> > >> However, I can't seem to remember in C++ or any other language > >> (not that I know all that many other languages) coming across a > >> function in the standard library that conflicted with another > >> function in the standard library in this way. I am likely to > >> get > >> corrected on that claim though :o) > > > > I'm sure that it could be found somewhere, but C++ avoids it > > for two reasons: > > > > 1. As good as the STL is, it's pathetically small. > > 2. It only uses one namespace, so it _has_ to avoid conflicts, > > even if that > > means using uglier names. > > > > Java or C# might have some conflicts (I'm not sure - they > > certainly have much > > richer standard libraries than C++ does), but they almost > > always avoid it, > > because they're don't even allow free functions, so you only > > end up having to > > worry about class names conflicting. Their module systems are > > also different > > from D's (particularly C#'s), which changes things a bit. > > > > Other languages like python tend to force you to give the full > > path anyway, > > which avoids conflicts. > > > > The reason that D runs into them is because the default is to > > pull everything > > into the current module when you import it. If we'd taken the > > approach of > > making you give the full import path by default or forcing you > > to explicitly > > import each symbol, then it wouldn't be a problem (though that > > would obviously > > cause other problems). > > > > And we'll definitely pick different names where appropriate, > > but if the best > > names for two different functions in two different modules > > happen to be the same > > name, then we're going to use it. And in same cases, we very > > purposely picked > > the same name, because the functions did the same type of thing > > (e.g. the > > functions in std.ascii and std.uni which do the same thing but > > for ASCII and > > Unicode respectively). > > > > - Jonathan M Davis > > That is an excellent explanation. Thank you. > > Do you think it would be worth noting the conflict in the > documentation for readText()/write()? > > I should have mentioned in my original post that I likely could > have figured out the workaround for this, and I posted here more > because I was surprised that std.stdio and std.file would have a > conflict! It seems like something folks new to D might run into > with some frequency, and be thinking "whats up with that!". > > If others think it is a good idea, maybe I will head over to > gitHub and try to add something.
I'm inclined to think that there's no need, since people learning D should know how the module system works, and I'd prefer not to clutter the documentation, but I also haven't been a newbie for a very long time. - Jonathan M Davis
