http://d.puremagic.com/issues/show_bug.cgi?id=10574
--- Comment #4 from monarchdo...@gmail.com 2013-07-09 03:56:35 PDT --- (In reply to comment #3) > (In reply to comment #2) > > Just an educated guess. The problem seems to be that the value is a L-value > > so > > the signature becomes (ref T[]) which cannot match immutable(int[]). > > That's exactly the current compiler's behavior. "auto ref" always behave as > "ref" parameter against lvalue argument `i`, then T[] cannot deduce type T > from > immutable(int[]). More generally, it seems auto ref will never operate a cast on an lvalue *even if* the parameter is not templatized. This is strange because auto ref *will* do it for RValues. Here is another (reduced) example that shows it. //---- void foo()(auto ref long a); void main() { int get(); int a; foo(get()); //Fine, rvalue int is cast to long foo(a); //Nope! } //---- main.d(7): Error: template main.foo does not match any function template declaration. Candidates are: main.d(1): main.foo()(auto ref long a) main.d(7): Error: template main.foo()(auto ref long a) cannot deduce template function from argument types !()(int) //---- I also spotted this (which, IMO, is even more problematic): //---- struct S { @property long get(); alias get this; } void foo()(auto ref long a); void main() { S s; foo(S()); //Fine. foo(s); //Nope! } //---- This time, it gives the "cryptic" error: main.d(14): Error: s.get() is not an lvalue => But that's strange: foo takes by auto ref... what do I care about lvalue? Because s is an Lvalue, it would appear the auto ref is "primed" to take by ref. It then fails when an actual Rvalue is given. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------