On 8/1/14, 6:08 PM, Dicebot wrote:
On Friday, 1 August 2014 at 17:06:24 UTC, Daniel Murphy wrote:
"Dicebot" wrote in message news:pnwgrcqfuhkzcaasa...@forum.dlang.org...
I am afraid we don't have the right way in D then. Caring about
cross-module name conflicts feels too much like plain C.
But with overloading!
It isn't just about avoiding conflicts - if the function name is
unique, you can tell what the code is doing without having to examine
the context so closely. This is especially important for the standard
library, because the time spent learning names can be reclaimed over
multiple projects.
If you find this important, you can always require renamed / static
imports in your projects. On the contrary, if function name is already
qualified with some redundant information, there is no simple way back
other than aliasing all symbols from that module.
I am convinced we are missing good style of using D import system, not
good names.
To an extent I agree, but I have to side with the view that common
artifacts in stdlib can cause quite some annoyance. I remember bug
reports being made about clashing symbols between (I forgot exactly)
std.string, std.regex, and std.algorithm. Clearly avoiding those clashes
was all business as usual, but that doesn't mean we can't make things a
tad better for standard library users.
Andrei
