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. ***