std.math conflicts with std.mathspecial

Jonathan M Davis jmdavisProg at gmx.com
Tue Jan 17 20:34:09 PST 2012


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


More information about the Digitalmars-d mailing list