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.

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

Make first read function templated too like this:

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

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?

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+

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.

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

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

> That was fixed in 2.064+

Cool, finally :)

-- 
/Jacob Carlborg

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

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