digitalmars.D.bugs - [Issue 8713] New: Allow passing arguments to templates in CTFE
- d-bugmail puremagic.com (41/41) Sep 23 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8713
- d-bugmail puremagic.com (24/24) Sep 24 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8713
- d-bugmail puremagic.com (8/22) Sep 24 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8713
- d-bugmail puremagic.com (32/32) Jul 24 2013 http://d.puremagic.com/issues/show_bug.cgi?id=8713
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=8713What 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
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