Bug 493 – Partial IFTI does not work

Status
RESOLVED
Resolution
FIXED
Severity
enhancement
Priority
P2
Component
dmd
Product
D
Version
D1 (retired)
Platform
All
OS
All
Creation time
2006-11-09T22:21:00Z
Last change time
2014-02-15T13:21:00Z
Assigned to
bugzilla
Creator
wbaxter
Blocks
1856

Attachments

IDFilenameSummaryContent-TypeSize
267partialifti-llvmdc.patchPatch to backport partial IFTI to dmd. Against llvmdc's dmd frontend. Should be similar to dmd 1.033.text/plain2504

Comments

Comment #0 by wbaxter — 2006-11-09T22:21:38Z
IFTI should try to deduce the parameter types for any template paramters not specified (if they don't have defaults). -------- import std.stdio:writefln; template foo(T,S) { void foo(T t, S s) { writefln("typeof(T)=",typeid(typeof(T))," typeof(S)=",typeid(typeof(S))); } } template bar(T,S) { void bar(S s) { writefln("typeof(T)=",typeid(typeof(T))," typeof(S)=",typeid(typeof(S))); } } void main() { // OK -- IFTI works happily foo(1.0,33); // OK -- Full template parameters specified bar!(double,int)(33); // error: I gave it T and it should be able to use IFTI to guess S, but it doesn't //bar!(float)(33); } --------------- Not sure if this should be a bug or an enhancement, but anyway, especially with the new variadic templates I think it will become more common to want to have a few specified paramters and let IFTI guess the rest. templatefunc(T, Var...)(Var v) { [...] } templatefunc!(SomeType)(a,b,c,d,e); This basically isn't usable if I have to specify all the types for a,b,c, and d.
Comment #1 by bugzilla — 2008-02-20T16:20:38Z
DMD 2.011 was enhanced to do this.
Comment #2 by wbaxter — 2008-02-20T21:40:48Z
(In reply to comment #1) > DMD 2.011 was enhanced to do this. > And this isn't a bug in D1 because...? As far as I can tell, the spec says only this about IFTI: """ Function templates can be explicitly instantiated ... or implicitly, where the TemplateArgumentList is deduced from the types of the function arguments """ It doesn't say anything about only working when it's convenient or when the stars are aligned properly. The conclusion I draw is that any failure to deduce a type when the information required to deduce it is there is a bug.
Comment #3 by wbaxter — 2008-02-20T21:46:32Z
By the way, that's great that it's fixed in D2. I can confirmed that it does indeed work with 2.011 (but not with 1.075).
Comment #4 by wbaxter — 2008-03-06T19:07:45Z
The new std.algorithm in DMD 2.011 uses this capability heavily. That means porting std.algorithm to D1 is basically not practical as of D2.011. I'm really going to be bummed if you hold to the line that fixes like this are really "enhancements" that will not be ported to D1.
Comment #5 by sean — 2008-05-18T08:50:02Z
This is a bug in DMD 1.0 so I'm sure it will be fixed eventually. And since basically all real development is with D 1.0, I sincerely hope we don't have to wait forever. This ticket was originally filed in 2006. It would be nice if #1650 were fixed at some point as well, since a rather fundamental example in the D book requires it to work correctly.
Comment #6 by kamm-removethis — 2008-08-09T04:00:50Z
Created attachment 267 Patch to backport partial IFTI to dmd. Against llvmdc's dmd frontend. Should be similar to dmd 1.033. I only did basic testing, but this patch seems to backport the D2 partial IFTI changes to D1. Should this go into llvmdc proper though? If we start diverging from Walter's definition of D1 too much we'll essentially create a D 1.5... People using this feature on llvmdc couldn't switch back to dmd easily.
Comment #7 by leandro.lucarella — 2008-11-13T13:36:51Z
I don't think is a good idea either to make ldc as buggy as DMD just to be compatible =)
Comment #8 by dfj1esp02 — 2008-12-01T08:26:57Z
It's the very purpose of compatibility to replicate bugs.
Comment #9 by fvbommel — 2008-12-01T09:02:11Z
(In reply to comment #8) > It's the very purpose of compatibility to replicate bugs. No, the very purpose of compatibility is to replicate *features*!
Comment #10 by bugzilla — 2008-12-25T04:40:31Z
Added to dmd 1.038