Bug 3556 – version(CTFE)

Status
RESOLVED
Resolution
FIXED
Severity
enhancement
Priority
P2
Component
dmd
Product
D
Version
D1 (retired)
Platform
Other
OS
All
Creation time
2009-11-28T18:04:00Z
Last change time
2014-04-18T09:12:06Z
Keywords
patch
Assigned to
nobody
Creator
bus_dbugzilla
Blocks
1924, 2066

Attachments

IDFilenameSummaryContent-TypeSize
542patch3556.patchPatch against DMD2 svn 324text/plain1849

Comments

Comment #0 by bus_dbugzilla — 2009-11-28T18:04:32Z
Until CTFE includes all features of runtime and has 100% same semantics as runtime (and maybe even after then), there is often a need to have separate codepaths for ctfe and runtime. A version(CTFE) would be an improvement over the current solution of making alternate CTFE-intended functions and using a naming convention to distinguish. version(CTFE) { // Sacrifice speed, flexibility, or anything else // necessary to make this code work via CTFE. } else { // Use proper D. }
Comment #1 by clugdbug — 2010-01-03T14:30:41Z
Created attachment 542 Patch against DMD2 svn 324 Here is a patch which adds __ctfe as a 'magic variable'. It's a bool which is true if evaluated in a function at compile-time, but false at run-time. If evaluated outside a function, it gives a "non-constant expression" error. Simple example: --------- import std.stdio; int foo() { if (__ctfe) return 3; writefln("run-time evaluated"); return 2; } static assert(foo()==3); void main() { assert(foo()==2); } -------- The back-end throws out the if(__ctfe){...} part (even without optimisations turned on), so there is no runtime penalty for adding if(__ctfe) clauses.
Comment #2 by bugzilla — 2010-01-11T22:05:10Z
Changeset 332
Comment #3 by bugzilla — 2010-01-11T22:06:43Z
The reason to prefer if(__ctfe) over version(CTFE) is that both code paths need to be compiled properly, as a function could be executed both at compile and runtime.
Comment #4 by leandro.lucarella — 2010-01-13T06:21:22Z
Being that D2 is close to finalization, why do you keep introducing language identifiers starting with __. I think it's a very bad idea, as they are historically used for implementation specific features.
Comment #5 by bugzilla — 2010-01-13T06:35:28Z
How about if (meta.inCTFE) { ... } for instance? (Assuming that __traits(xxx) becomes meta.xxx, of course.)
Comment #6 by clugdbug — 2010-01-13T06:55:16Z
(In reply to comment #4) > Being that D2 is close to finalization, why do you keep introducing language > identifiers starting with __. I think it's a very bad idea, as they are > historically used for implementation specific features. This *is* an implementation-specific feature. The user interface is not yet determined. Note that you can already write: ----- module meta; alias __ctfe inCTFE; -----
Comment #7 by bugzilla — 2010-01-30T22:45:33Z
fixed dmd 2.040
Comment #8 by smjg — 2010-01-31T06:16:49Z
(In reply to comment #4) > Being that D2 is close to finalization, What are you talking about? Not even D1 is finished yet, therefore what you say is impossible.