Bug 4953 – Regression(2.031): templates don't do implicit conversion properly

Given this struct: struct S { short _x; bool opBinaryRight(string op)(short x) if (op == "in") { return x == _x; } } void main() { S s; 5 in s; } This produces the error: testopin.d(13): Error: rvalue of in expression must be an associative array, not S But change the type of x to int, and it works. However, the type of the argument should play no role in whether the template can be instantiated. It seems this is the error message that is given when a type does not support opIn, so the error message is very bad too. Slightly related, but not the same issue: bug 3905

Further evidence, this compiles: void main() { S s; s.opBinaryRight!"in"(5); }

(In reply to comment #1) > Further evidence, this compiles: > > void main() > { > S s; > s.opBinaryRight!"in"(5); > } This is not specific to "in". The code below fails to compile, but it works if you change "short" to "int". struct S { void opBinary(string op)(short x) {} } void main() { S s; s + 5; } Original title for this bug was: opBinaryRight for "in" doesn't work right

Wow. This is a lot more general than I thought. Consider this code: void foo(T = void)(short x) {} void main() { foo(5); } This compiled in 2.030, failed in 2.031 and later. However, if you change 'short' to 'long', it works. It's because of mtype.c, TypeBasic::implicitConvTo(), line 3010. Implicit conversion to a smaller size is disallowed. That's fine in general, but shouldn't be true of template deduction.

Another example: void foo(T = void)(short x) {} void main() { foo(5_000_000); }

(In reply to comment #5) > https://github.com/D-Programming-Language/dmd/pull/239 The patch breaks the test suite.

(In reply to comment #6) > (In reply to comment #5) > > https://github.com/D-Programming-Language/dmd/pull/239 > > The patch breaks the test suite. Redone: https://github.com/D-Programming-Language/dmd/pull/269

*** Issue 6567 has been marked as a duplicate of this issue. ***

Yet another example: module main; struct MyStruct { void funOpAssign(float[1u] data) { } void opOpAssign(string op)(float[1u] data) if(op=="<<") { } } int main(string[] argv) { // dmd v2.054, v2.055 MyStruct s; float[1u] a = [1.0f]; // OK: Implicit cast from float[] compiles s.funOpAssign([1.0f]); // OK: Implicit cast from float[] compiles s <<= [1.0f]; // Issue: Implicit cast from float[] does not compile s <<= cast(float[1u])[1.0f]; // OK: Explicit cast from float[] compiles return 0; }

The pull is still valid (if in need of a rebase) but the solution needs a decision from Walter on how the match level problem is going to be solved in the future. See issue 2367 for another example.

Another data point: void f(dstring d) { dstring e = d; } f("abc"); // OK void f()(dstring d) { dstring e = d; } f("abc"); // OK void f(byte[] b) { byte[] c = b; } f([1,2,3]); // OK void f()(byte[] b) { byte[] c = b; } f([1,2,3]); // Error: template test2.f() does not match any function template declaration // Error: template test2.f() cannot deduce template function from argument types !()(int[])

Looking at this history of this bug and the pulls in github, it looks like there isn't a valid pull request that fixes this bug right now. Removing the keyword.

(In reply to comment #13) > Looking at this history of this bug and the pulls in github, it looks like > there isn't a valid pull request that fixes this bug right now. Removing the > keyword. My dmd/pull/45 fixes both bug 5896 and this. I think the two bugs need the changes of each other. Please keep 'pull' keyword.

I'll add it back, but it looked like Walter was rejecting the pull request. It is still open, so might as well leave them linked. Walter, would you put regression pull requests such as this one near the top of your todo list? Either reject with reasons or pull. Limbo sucks.

Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/91093c7bb19b2f43dffa868c5f8125e1bd347412 fix Issue 4953 - Regression(2.031): templates don't do implicit conversion properly

*** Issue 7366 has been marked as a duplicate of this issue. ***