std.math conflicts with std.mathspecial

[Jun]

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.)