On Wednesday, 18 January 2012 at 04:35:17 UTC, Jonathan M Davis
wrote:
On Wednesday, January 18, 2012 02:14:41 F i L wrote:
Also, you can do:
import std.math;
import special = std.mathspecial;
void main()
{
writeln(special.erf(0.5));
}
See http://www.d-programming-language.org/module.html for more
information.
I believe that his argument is that when there is a conflict
and one of the two functions is deprecated (and you're not
compiling with -d), then the deprecated function shouldn't be
considered as part of the overload set. I'm not sure whether
this is a good idea or not.
With the current situation, you're forced to qualify the
non-deprecated function, and your code will continue working
after that (even after the deprecated function has been
removed), but you'll be stuck with unnecessarily qualified
function calls in the longe run.
On the other hand, if we were to switch to what the OP
suggests, then different if a function were deprecated and
another matching function were added at the same time, then
your code would silently start calling the new function,
possibly resulting in incorrect behavior.
Regardless, since private functions are included in overload
resolution (see
http://d.puremagic.com/issues/show_bug.cgi?id=1441 and more
discussion of it in
http://d.puremagic.com/issues/show_bug.cgi?id=6180 ), I
wouldn't expect deprecated functions to be removed from
overload resolution.
On the bright side, the deprecated function won't be around in
the long run, so it's a temporary issue.
- Jonathan M Davis
I see. Well, It's unlikely for me to use those functions in
std.mathspecial again. I just thought keep adding qualifier was a
bit annoying. I didn't know such incorrect behavior can happen.
Thanks for your reply. (And, I'm sorry if you(and others who read
this) had some problem understanding my bad english.)
