www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 8713] New: Allow passing arguments to templates in CTFE

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8713

           Summary: Allow passing arguments to templates in CTFE
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: jens.k.mueller gmx.de



When doing CTFE it may be worthwhile to allow passing of function arguments to
template instantiations. This eases better integration between templates and
CTFE making meta programming more convenient.
Example:

bool foo(string a)                                                              
{                                                                               
    return bar!(a);                                                             
}                                                                               

template bar(string b)                                                          
{                                                                               
    enum bar = true;                                                            
}

fails to compile with
test.d(3): Error: variable a cannot be read at compile time

The problem is that foo must be compilable to be executed at run-time which
clearly cannot work with the above code. But if __ctfe was a compile-time known
value foo could be written like:
static if (__ctfe)
{
    return bar!(a)
}
else
{
    return false;
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 23 2012
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8713


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au



What you are asking for is this:
(a) things wrapped in if (__ctfe) don't get fully semantically checked when the
function is compiled.
(Specifically, anything which needs a compile-time value doesn't get checked
for 'readable at compile time').

(b) CTFE functions never get compiled. When a template is encountered inside a
CTFE function, it is created during execution of the function.

Your enhancement request acts as if (a) is the problem, but it isn't. (a) is an
intentional restriction to protect us from (b) which is very, very nasty. It's
not merely implementation issues (although they are formidable). Fundamentally
it violates the independence of the compiler passes, which is crucial to the
design of D (you always finish one pass before you start the next).

Just to name one problem: accepting this request would make it impossible to
have a clean JIT-based implementation of CTFE. Because of this I think it
closes more doors than it opens.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 24 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8713





 What you are asking for is this:
 (a) things wrapped in if (__ctfe) don't get fully semantically checked when the
 function is compiled.
 (Specifically, anything which needs a compile-time value doesn't get checked
 for 'readable at compile time').
 
 (b) CTFE functions never get compiled. When a template is encountered inside a
 CTFE function, it is created during execution of the function.
 
 Your enhancement request acts as if (a) is the problem, but it isn't. (a) is an
 intentional restriction to protect us from (b) which is very, very nasty. It's
 not merely implementation issues (although they are formidable). Fundamentally
 it violates the independence of the compiler passes, which is crucial to the
 design of D (you always finish one pass before you start the next).
Why is the independence of compiler passes crucial to the design of D? What would break if the compiler was implemented differently? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 24 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8713


Don <clugdbug yahoo.com.au> changed:

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



This idea has some severe problems. For example, this code currently compiles:
---
int foo(int x) { return 1; }

auto bar(int x) 
{
    if (__ctfe)
        return foo(x);
    assert(0);
}

auto baz(int x) { return bar(x); }
-------
But if you changed that to return foo!(x), and defined foo as:

template foo(int x)
{
    static if (x == 0) enum foo = 0.0;
    else enum foo = "abc";    
}

then baz doesn't have a return type -- the return type of baz(0) is different
to the return type of baz(1). You get no idea of this from reading baz() on its
own.

This is merely one of many problems with this idea. Closing this as invalid. At
the very least, it would need a DIP.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 24 2013