In the following code, a shortcoming of current type inference is pointed out: struct foo(T) { T data; static foo!(T) opCall(T t) { foo!(T) result; result.data = t; return result; } } auto f = foo(4); The line with 'f = foo(4)' gives a template instantiation error, while it should be possible for the compiler to infer the template parameters from the call. auto g = foo!(int)(4); This works, but is nowhere near as pretty.
DMD includes private methods when it tries to match for type inference even though the private function is not available. .\test.d(10): Error: template bar.Bar(T) does not match any function template declaration .\test.d(10): Error: template bar.Bar(T) cannot deduce template function from argument types !()(void delegate()) ------------------ module bar; import foo; void Bar(T)(void delegate(T) call) { } void main() { auto foo = new Foo(); Bar(&foo.fish); } ------------------ module foo; class Foo { private void fish() { } public void fish(string color) { } }
It is worth noting here that the workaround is to use a free function: struct Foo( T ) { T data; this( T value ) { data = value; } } Foo!T foo( T )( T value ) { return Foo!T( value ); } void main( ) { foo( 4 ); }
This issue is not fixable in the general case - constructor arguments do not necessarily line up with type arguments. As pointed out above, the correct fix is to use a factory function.
*** Issue 21106 has been marked as a duplicate of this issue. ***