• Jun (19/19) Jan 17 2012 import std.math;
• F i L (7/7) Jan 17 2012 import std.stdio;
• F i L (14/14) Jan 17 2012 Whoops, forgot "std" before "mathspecial":
• F i L (9/9) Jan 17 2012 Also, you can do:
• Jonathan M Davis (20/32) Jan 17 2012 I believe that his argument is that when there is a conflict and one of ...
• Don Clugston (20/52) Jan 18 2012 I'm not sure that that's the same. It's interesting to compare these two...
• Jun (7/45) Jan 18 2012 I see. Well, It's unlikely for me to use those functions in
• Don (4/49) Jan 18 2012 There are so few users of those functions, that it's probably safe to

"Jun" <blings naver.com> writes:

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.

"F i L" <witte2008 gmail.com> writes:

import std.stdio;
import std.math;
import std.mathspecial;

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

"F i L" <witte2008 gmail.com> writes:

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));
    }

"F i L" <witte2008 gmail.com> writes:

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.

Jonathan M Davis <jmdavisProg gmx.com> writes:

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

Don Clugston <dac nospam.com> writes:

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

"Jun" <blings naver.com> writes:

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

Don <nospam nospam.com> writes:

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