Conflict between std.file write() and std.stdio write()

[Jonathan M Davis]

On Thursday, October 03, 2013 20:57:20 Craig Dillabaugh wrote:
> On Thursday, 3 October 2013 at 18:12:01 UTC, Jonathan M Davis
> 
> wrote:
> > On Thursday, October 03, 2013 15:22:28 Craig Dillabaugh wrote:
> >> It seems that std.file should include a writeText() function
> >> for
> >> the sake of consistency that is the above alias. When you come
> >> across readText() in the documentation you sort of expect that
> >> such a function would exist, and then you spot write() below
> >> it,
> >> and think hey that does what I need. Then you hit upon the
> >> syntax error if you are also using std.stdio (which is a very
> >> commonly used module).
> >> 
> >> Adding writeText() doesn't really add much to the library, but
> >> having to jump through hoops (as minor as they may be) to
> >> perform
> >> such a simple op is a bit of a pain for people new to the
> >> language.
> > 
> > writeText would be redundant. write will already write
> > arbitrary data to a file
> > - including strings. writeText would add no functionality.
> > Functions should
> > add actual value, or they just clutter up the library.
> > 
> > Conflicting functions is just part of life. The module system
> > is designed to
> > let you disambiguate them. We're not going to try and make all
> > of the function
> > names unique just because you might import a module with a
> > conflicting
> > function. If write is the best name for the function, then
> > that's what we'll
> > use, even if it conflicts with a function in another module. To
> > do otherwise
> > would be to ignore the features of the module system and force
> > us to come up
> > with worse names just to avoid conflicts.
> > 
> > - 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