Bug 1997 – Better type inference for templated types

Status
RESOLVED
Resolution
WONTFIX
Severity
enhancement
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2008-04-15T19:36:24Z
Last change time
2020-08-04T08:25:01Z
Assigned to
No Owner
Creator
Simen Kjaeraas

Comments

Comment #0 by simen.kjaras — 2008-04-15T19:36:24Z
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.
Comment #1 by Jesse.K.Phillips+D — 2010-03-10T08:46:35Z
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) { } }
Comment #2 by simen.kjaras — 2011-09-16T08:17:12Z
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 ); }
Comment #3 by simen.kjaras — 2017-06-28T08:58:11Z
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.
Comment #4 by simen.kjaras — 2020-08-04T08:25:01Z
*** Issue 21106 has been marked as a duplicate of this issue. ***