January 18, 2012
import std.math;
import std.mathspecial; import std.stdio; void main(string[] args) {
 writeln(erf(0.5));
}
Well... I was wating for any reply about this but I got nothing.. so I decided to re-post this. If I compile this code, I get this message. D:\D\dmd2\windows\bin\mathconflict.d(7): Error: std.mathspecial.erf at D:\D\dmd2 \windows\bin\..\..\src\phobos\std\mathspecial.d(273) conflicts with std.math.erf at D:\D\dmd2\windows\bin\..\..\src\phobos\std\math.d(1923) and if I try using deprecated one...
import std.math;
import std.stdio; void main(string[] args) {
  writeln(erf(0.5)); }  I get this. D:\D\dmd2\windows\bin\mathconflict.d(6): Error: function std.math.erf is deprecated
I think deprecated function should not cause conflict.
January 18, 2012
import std.stdio;
import std.math;
import std.mathspecial;

void main()
{
   writeln(mathspecial.erf(0.5));
}
January 18, 2012
Whoops, forgot "std" before "mathspecial":

   import std.math;
   import std.mathspecial;

   void main()
   {
       writeln(std.mathspecial.erf(0.5));
   }

or you could do:

   import std.math;
   import std.mathspecial : erf;

   void main()
   {
       writeln(erf(0.5));
   }


January 18, 2012
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.
January 18, 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
January 18, 2012
On 18/01/12 05:34, 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.

I'm not sure that that's the same. It's interesting to compare these two:

deprecated {
   void foo1() {}
}

version(deprecated)
{
   void foo2() {}
}

If compiled with -d, both foo1() and foo2() are identical.
If not compiled with -d, foo2() doesn't even exist.
But foo1() generates an error message if you try to use it.

Really the question is, should foo1() generate an error message if you *might* be trying to use it? Or only if you are *definitely* trying to use it?

My opinion is that it should be almost the same as foo2(): the declaration exists ONLY for the purpose of generating a "must use -d" if you try to call it. It's purely a service to help people migrate their code. It should have no effect on people who have already migrated their code.



>
> On the bright side, the deprecated function won't be around in the long run,
> so it's a temporary issue.
>
> - Jonathan M Davis

January 18, 2012
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.)
January 18, 2012
On 18.01.2012 11:36, Jun wrote:
> 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.)

There are so few users of those functions, that it's probably safe to remove them from std.math very soon. Their replacements in std.mathspecial have been around for a very long time (more than a year).


Top | Discussion index | About this forum | D home