On Sun, Aug 1, 2010 at 11:15 PM, Philippe Sigaud <philippe.sig...@gmail.com>wrote:
> > > On Sat, Jul 31, 2010 at 17:24, Andrej Mitrovic <andrej.mitrov...@gmail.com > > wrote: > >> I think there really is some bug here. I tried to use your template helper >> function, and it seems the order in which I put two constraints in a >> template signature changes the way dmd compiles the code. Consider this: >> > > >> T[] find(T, E)(T[] haystack, E needle) >> if (is(typeof(haystack[0] != needle) == bool) && >> areComparable!(T, E)) >> >> ... > > >> T1[] find(T1, T2)(T1[] longer, T2[] shorter) >> if (is(typeof(longer[0 .. 1] == shorter) : bool) && >> (areComparable!(T1, T2))) >> > > > >> This will give out the error "incompatible types for comparing of string >> and immutable(char)". >> > > That's because the first part of the constraint is tested, to allow for > short-circuiting the second part. So the bad array comparison triggers the > problem in object._EqArray. > > You should always test for the most general constraint first, I guess. In > this particular case, use areComparable!(A,B) as the first argument to && in > both templates. > > Let me see if I'm getting this right. false && true will short circuit to false (this is normal). true && false will short circuit to true? How can that be? It's not a logical OR, its an AND, and as far as I know both expressions need to be True to evaluate to True. Or is it different for template constraints? Thanks again for the std.math.approxEqual and binaryFun tips.