• kdmult (31/31) Dec 19 2013 Hi,
• Jacob Carlborg (9/39) Dec 19 2013 I'm wondering if that's because the first "read" isn't a template
• Andrej Mitrovic (2/4) Dec 20 2013 That was fixed in 2.064+
• Jacob Carlborg (4/5) Dec 20 2013 Cool, finally :)
• Andrej Mitrovic (2/5) Dec 20 2013 Yeah, it caused many headaches. Fixed thanks to Kenji, of course (who el...
• Jacob Carlborg (4/5) Dec 20 2013 Yeah, he's doing a lot of good work :)
• FreeSlave (2/2) Dec 20 2013 Make first read function templated too like this:
• kdmult (16/18) Dec 20 2013 In fact, there are workarouns. But why the order of the
• Andrej Mitrovic (2/4) Dec 20 2013 I think you should file this as a bug.
• kdmult (4/8) Dec 20 2013 Done.

"kdmult" <kdmult ya.ru> writes:

Hi,

Why compilation depends on order of method declarations?

The following test case does not compile.

However, if we change the order of the 'read' methods in class 
InputStream below then  compilation will not fail.

Is it a bug?

---
module test;

import std.traits : isBasicType;
import std.typetuple : TypeTuple;

class InputStream {

     long read( ubyte* bytes, long len )
     {
         return 0;
     }

     void read(T)( ref T val ) if (isBasicType!T)
     {
         read(cast(ubyte*)&val, cast(long)val.sizeof);
     }

}

void main()
{
     auto input = new InputStream;

     foreach (T; TypeTuple!(long, int, short, byte))
     {
         T v;
         input.read(v);
     }
}
---

Thanks.

Jacob Carlborg <doob me.com> writes:

On 2013-12-20 08:03, kdmult wrote:
 Hi,

 Why compilation depends on order of method declarations?

 The following test case does not compile.

 However, if we change the order of the 'read' methods in class
 InputStream below then  compilation will not fail.

 Is it a bug?

 ---
 module test;

 import std.traits : isBasicType;
 import std.typetuple : TypeTuple;

 class InputStream {

      long read( ubyte* bytes, long len )
      {
          return 0;
      }

      void read(T)( ref T val ) if (isBasicType!T)
      {
          read(cast(ubyte*)&val, cast(long)val.sizeof);
      }

 }

 void main()
 {
      auto input = new InputStream;

      foreach (T; TypeTuple!(long, int, short, byte))
      {
          T v;
          input.read(v);
      }
 }
 ---

I'm wondering if that's because the first "read" isn't a template 
function. You cannot overload a standard function with a template 
function, or has that been fixed?

If that's not the problem it's probably the template constraint. I have 
had some problems with that and the "solution" I end up using was to add 
the same template constraint to the other function but negate the condition.

-- 
/Jacob Carlborg

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

On 12/20/13, Jacob Carlborg <doob me.com> wrote:
 You cannot overload a standard function with a template
 function, or has that been fixed?

That was fixed in 2.064+

Jacob Carlborg <doob me.com> writes:

On 2013-12-20 09:42, Andrej Mitrovic wrote:

 That was fixed in 2.064+

Cool, finally :)

-- 
/Jacob Carlborg

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

On 12/20/13, Jacob Carlborg <doob me.com> wrote:
 On 2013-12-20 09:42, Andrej Mitrovic wrote:

 That was fixed in 2.064+

 Cool, finally :)

Yeah, it caused many headaches. Fixed thanks to Kenji, of course (who else?).

Jacob Carlborg <doob me.com> writes:

On 2013-12-20 15:28, Andrej Mitrovic wrote:

 Yeah, it caused many headaches. Fixed thanks to Kenji, of course (who else?).

Yeah, he's doing a lot of good work :)

-- 
/Jacob Carlborg

"FreeSlave" <freeslave93 gmail.com> writes:

Make first read function templated too like this:

long read()( ubyte* bytes, long len )

"kdmult" <kdmult ya.ru> writes:

On Friday, 20 December 2013 at 08:03:26 UTC, FreeSlave wrote:
 Make first read function templated too like this:

 long read()( ubyte* bytes, long len )

In fact, there are workarouns. But why the order of the 
declarations has an effect on the compilation result.

Namely, if the templated overloaded function goes after the 
non-templated one then the compilation fails.
FAILED:
long read( ubyte* bytes, long len ) { return 0; }
void read(T)( ref T val ) { read(cast(ubyte*)&val, 
cast(long)val.sizeof); }

Otherwise, if the templated overloaded function goes before the 
non-templated one then the compilation is successful.
SUCCEEDED:
void read(T)( ref T val ) { read(cast(ubyte*)&val, 
cast(long)val.sizeof); }
long read( ubyte* bytes, long len ) { return 0; }

Why?

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

On 12/20/13, kdmult <kdmult ya.ru> wrote:
 But why the order of the
 declarations has an effect on the compilation result.

I think you should file this as a bug.

"kdmult" <kdmult ya.ru> writes:

On Friday, 20 December 2013 at 08:42:34 UTC, Andrej Mitrovic 
wrote:
 On 12/20/13, kdmult <kdmult ya.ru> wrote:
 But why the order of the
 declarations has an effect on the compilation result.

 I think you should file this as a bug.

Done.
https://d.puremagic.com/issues/show_bug.cgi?id=11785