www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Compiler silently ignores some method overloads

reply pineapple <meapineapple gmail.com> writes:
In my struct I have some methods with these signatures:

     void opIndexAssign(T)(in GLColor!T color, in int x, in int y)
     void opIndexAssign(T1, T2)(in GLColor!T1 color, in Vector2!T2 
vector)
     void opIndexAssign(in uint value, in int x, in int y)

And when I try to do this:

     thing[2, 2] = GLColor!float(1, 1, 1);

I get a compiler error like so:

     E:\Dropbox\Projects\d\mach\sdl\surface.d(434): Error: none of 
the overloads of 'opIndexAssign' are callable using argument 
types (GLColor!float, int, int), candidates are:
     E:\Dropbox\Projects\d\mach\sdl\surface.d(406):        
mach.sdl.surface.Surface.opIndexAssign(const(uint) value, 
const(int) x, const(int) y)

Meaning the overloads using GLColor are apparently silently 
ignored?

I had the same problem with another method. Here are my overloads:

     void fill(in uint color)
     void fill(T)(in GLColor!T color)
     void fill(in ubyte r, in ubyte g, in ubyte b, in ubyte a = 
255)
     void fill(in Box!int box, in uint color)
     void fill(T)(in Box!int box, in GLColor!T color)
     void fill(in Box!int box, in ubyte r, in ubyte g, in ubyte b, 
in ubyte a = 255)
     void fill(in SDL_Rect* rect, in uint color)

And when I try to do this:

     thing.fill(GLColor!float(1, 1, 1));

I get another compiler error:

     E:\Dropbox\Projects\d\mach\sdl\surface.d(429): Error: none of 
the overloads of 'fill' are callable using argument types 
(GLColor!float), candidates are:
     E:\Dropbox\Projects\d\mach\sdl\surface.d(179):        
mach.sdl.surface.Surface.fill(const(uint) color)
     E:\Dropbox\Projects\d\mach\sdl\surface.d(187):        
mach.sdl.surface.Surface.fill(const(ubyte) r, const(ubyte) g, 
const(ubyte) b, const(ubyte) a = cast(ubyte)255u)
     E:\Dropbox\Projects\d\mach\sdl\surface.d(191):        
mach.sdl.surface.Surface.fill(const(Box!int) box, const(uint) 
color)
     E:\Dropbox\Projects\d\mach\sdl\surface.d(199):        
mach.sdl.surface.Surface.fill(const(Box!int) box, const(ubyte) r, 
const(ubyte) g, const(ubyte) b, const(ubyte) a = cast(ubyte)255u)
     E:\Dropbox\Projects\d\mach\sdl\surface.d(203):        
mach.sdl.surface.Surface.fill(const(SDL_Rect*) rect, const(uint) 
color)

The module containing the GLColor struct is definitely imported 
correctly, and I don't see how this could be an issue with the 
GLColor since its (admittedly meager) unittests all pass.

What am I missing?
May 08 2016
parent reply Peter =?UTF-8?B?SMOkZ2dtYW4=?= <hagg.pet2 online.fi> writes:
On Sunday, 8 May 2016 at 13:28:47 UTC, pineapple wrote:

 [...]
 I get a compiler error like so:

     E:\Dropbox\Projects\d\mach\sdl\surface.d(434): Error: none 
 of the overloads of 'opIndexAssign' are callable using argument 
 types (GLColor!float, int, int), candidates are:
     E:\Dropbox\Projects\d\mach\sdl\surface.d(406):        
 mach.sdl.surface.Surface.opIndexAssign(const(uint) value, 
 const(int) x, const(int) y)

 Meaning the overloads using GLColor are apparently silently 
 ignored?


No they are not ignored, otherwise the following would not 
compile:

----
struct GLColor(T){T t0,t1,t2;}

struct Thing
{
     void opIndexAssign(T)(in GLColor!T color, in int x, in int 
y){}
     void opIndexAssign(T1, T2)(in GLColor!T1 color, in Vector2!T2 
vector){}
     void opIndexAssign(in uint value, in int x, in int y){}
}

void main(string[] args)
{
     Thing thing;
     thing[2,2] = GLColor!float(1, 1, 1);
}
----

Can you show your GLColor struct ? Maybe it contains an alias 
this or something else that mess the overload resolution.
May 08 2016
parent reply pineapple <meapineapple gmail.com> writes:
On Monday, 9 May 2016 at 00:27:17 UTC, Peter Häggman wrote:

 Can you show your GLColor struct ? Maybe it contains an alias 
 this or something else that mess the overload resolution.


My GLColor struct: http://pastebin.com/mUcA6G85
May 09 2016
parent reply Peter =?UTF-8?B?SMOkZ2dtYW4=?= <HildigardSandyman inbound.plus> writes:
On Monday, 9 May 2016 at 11:22:37 UTC, pineapple wrote:

 On Monday, 9 May 2016 at 00:27:17 UTC, Peter Häggman wrote:

 Can you show your GLColor struct ? Maybe it contains an alias 
 this or something else that mess the overload resolution.


 My GLColor struct: http://pastebin.com/mUcA6G85


No problem here (tested with everything in a single module). I 
can't help more.
Front end version ?
May 09 2016
parent reply pineapple <meapineapple gmail.com> writes:
On Monday, 9 May 2016 at 18:56:15 UTC, Peter Häggman wrote:

 No problem here (tested with everything in a single module). I 
 can't help more.
 Front end version ?


Well, this is the full struct that has those malfeasant 
overrides: http://pastebin.com/9h2s028J
May 10 2016
parent reply pineapple <meapineapple gmail.com> writes:
On Tuesday, 10 May 2016 at 09:57:11 UTC, pineapple wrote:

 On Monday, 9 May 2016 at 18:56:15 UTC, Peter Häggman wrote:

 No problem here (tested with everything in a single module). I 
 can't help more.
 Front end version ?


 Well, this is the full struct that has those malfeasant 
 overrides: http://pastebin.com/9h2s028J


I found the problem -

It turns out I was importing that glcolor module at both the top 
of the file and in a version(unittest) block. I'm not sure _why_ 
that broke things, but removing the redundant unittest import 
fixed my problem.
May 10 2016
parent Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Tuesday, 10 May 2016 at 22:17:00 UTC, pineapple wrote:

 On Tuesday, 10 May 2016 at 09:57:11 UTC, pineapple wrote:

 On Monday, 9 May 2016 at 18:56:15 UTC, Peter Häggman wrote:

 No problem here (tested with everything in a single module). 
 I can't help more.
 Front end version ?


 Well, this is the full struct that has those malfeasant 
 overrides: http://pastebin.com/9h2s028J


 I found the problem -

 It turns out I was importing that glcolor module at both the 
 top of the file and in a version(unittest) block. I'm not sure 
 _why_ that broke things, but removing the redundant unittest 
 import fixed my problem.


This looks like a bug. Please report it at 
https://issues.dlang.org/ , if possible with a minimal example, 
thanks!
May 11 2016