Jump to page: 1 2
Thread overview
[Issue 493] New: Partial IFTI does not work
Nov 10, 2006
d-bugmail
Feb 20, 2008
d-bugmail
Feb 21, 2008
d-bugmail
Feb 21, 2008
d-bugmail
Mar 07, 2008
d-bugmail
May 18, 2008
d-bugmail
Aug 09, 2008
d-bugmail
Nov 13, 2008
d-bugmail
Dec 01, 2008
d-bugmail
Dec 01, 2008
d-bugmail
Dec 10, 2008
d-bugmail
Dec 25, 2008
d-bugmail
November 10, 2006
http://d.puremagic.com/issues/show_bug.cgi?id=493

           Summary: Partial IFTI does not work
           Product: D
           Version: 0.173
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: wbaxter@gmail.com


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.


-- 

February 20, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=493


bugzilla@digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #1 from bugzilla@digitalmars.com  2008-02-20 16:20 -------
DMD 2.011 was enhanced to do this.


-- 

February 21, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=493


wbaxter@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




------- Comment #2 from wbaxter@gmail.com  2008-02-20 21:40 -------
(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.


-- 

February 21, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=493





------- Comment #3 from wbaxter@gmail.com  2008-02-20 21:46 -------
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).


-- 

March 07, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=493





------- Comment #4 from wbaxter@gmail.com  2008-03-06 19:07 -------
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.


-- 

May 18, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=493





------- Comment #5 from sean@invisibleduck.org  2008-05-18 08:50 -------
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.


-- 

August 09, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=493





------- Comment #6 from kamm-removethis@incasoftware.de  2008-08-09 04:00 -------
Created an attachment (id=267)
 --> (http://d.puremagic.com/issues/attachment.cgi?id=267&action=view)
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.


-- 

November 13, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=493





------- Comment #7 from llucax@gmail.com  2008-11-13 13:36 -------
I don't think is a good idea either to make ldc as buggy as DMD just to be compatible =)


-- 

December 01, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=493





------- Comment #8 from maxmo@pochta.ru  2008-12-01 08:26 -------
It's the very purpose of compatibility to replicate bugs.


-- 

December 01, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=493





------- Comment #9 from fvbommel@wxs.nl  2008-12-01 09:02 -------
(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*!


-- 

« First   ‹ Prev
1 2