void foo(int delegate(ref int[1]) spam) {} void main() { foo((ref int[1] x) => 0); // OK foo(x => 0); // Error } DMD 2.062alpha gives: test.d(4): Error: function test.foo (int delegate(ref int[1u]) spam)(null) is not callable using argument types (void) test.d(4): Error: cannot implicitly convert expression (__lambda3) of type int delegate(int[1u] x) pure nothrow @safe to int delegate(ref int[1u])
When I fixed bug7705, I decided that lambda inference does not infer parameter storage classes. Instead, users should specify `ref`/`out`/`lazy` explicitly. https://github.com/D-Programming-Language/dmd/pull/809/files#L1R496 Because, explicit specifying of `ref` in call site is sometimes required in newsgroup. void foo(ref int x) {} int n; foo(ref n); // not allowed in today So, current behavior is intended. You should write it as follows: void foo(int delegate(ref int[1]) spam) {} void main() { foo((ref x) => 0); // OK } However, I cannot say clearly whether it's right behavior. I think that the opinion "parameter storage classes should be inferred" is also worth. Therefore, I'll mark this as 'enhancement'. ===== A pull to implement this feature: https://github.com/D-Programming-Language/dmd/pull/1580
(In reply to comment #1) > Therefore, I'll mark this as 'enhancement'. > > ===== > > A pull to implement this feature: > https://github.com/D-Programming-Language/dmd/pull/1580 Thank you Hara.
A discussion thread, the answers are mixed: http://forum.dlang.org/thread/mixmakdqfmaznmmnizux@forum.dlang.org A comment from Timon Gehr: > BTW, the pull does not contain a test for the case > > void foo(int delegate(int) dg){ ... } // 1 > void foo(int delegate(ref int) dg){ ... } // 2 > > void main(){ foo(x=>0); } // call 1
*** Issue 12830 has been marked as a duplicate of this issue. ***
Closing in favor of 11316, since that one covers all storage classes, not just ref. *** This issue has been marked as a duplicate of issue 11316 ***