[Issue 8713] Allow passing arguments to templates in CTFE

2013-07-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8713


Don  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


--- Comment #3 from Don  2013-07-24 11:19:29 PDT ---
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: ---


[Issue 8713] Allow passing arguments to templates in CTFE

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8713



--- Comment #2 from jens.k.muel...@gmx.de 2012-09-24 05:33:43 PDT ---
(In reply to comment #1)
> 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: ---


[Issue 8713] Allow passing arguments to templates in CTFE

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8713


Don  changed:

   What|Removed |Added

 CC||clugd...@yahoo.com.au


--- Comment #1 from Don  2012-09-24 05:04:56 PDT ---
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: ---