www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - CTFE: What limitations remain?

reply dsimcha <dsimcha yahoo.com> writes:
The documentation for CTFE is outdated and specifies limitations that no
longer exist thanks to Don's massive overhaul.  For example, a big one is that
pointers now work.  What limitations that could potentially be removed still
do exist in CTFE as of 2.054?
Jul 12 2011
next sibling parent d coder <dlang.coder gmail.com> writes:
--0015173fee5ea5f61904a7e0b3db
Content-Type: text/plain; charset=ISO-8859-1

For example, a big one is that
 pointers now work.

Do function pointers work? --0015173fee5ea5f61904a7e0b3db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">For exa= mple, a big one is that<br> pointers now work.=A0</blockquote><div><br></div><div>Do function pointers = work?</div><div>=A0</div></div> --0015173fee5ea5f61904a7e0b3db--
Jul 12 2011
prev sibling next sibling parent Johann MacDonagh <johann.macdonagh..no spam..gmail.com> writes:
On 7/12/2011 10:22 AM, dsimcha wrote:
 The documentation for CTFE is outdated and specifies limitations that no
 longer exist thanks to Don's massive overhaul.  For example, a big one is that
 pointers now work.  What limitations that could potentially be removed still
 do exist in CTFE as of 2.054?

Right now I'm up against two limitations: http://d.puremagic.com/issues/show_bug.cgi?id=4046 http://d.puremagic.com/issues/show_bug.cgi?id=6268 That being said, I am amazed at what I can get away with now with CTFE. I find myself saying "there's no way I can do that", then testing out with enum x = theresNoWay(); and being amazed at the clean compile.
Jul 12 2011
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 12.07.2011 18:22, dsimcha wrote:
 The documentation for CTFE is outdated and specifies limitations that no
 longer exist thanks to Don's massive overhaul.  For example, a big one is that
 pointers now work.  What limitations that could potentially be removed still
 do exist in CTFE as of 2.054?

- try/catch - intrinsics (bsr, bsf etc. ) this currently also means no Appender - array.reserve - foreach over tupple (aka static foreach) -- Dmitry Olshansky
Jul 12 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 13 Jul 2011 02:32:41 -0400, Dmitry Olshansky  
<dmitry.olsh gmail.com> wrote:

 On 12.07.2011 18:22, dsimcha wrote:
 The documentation for CTFE is outdated and specifies limitations that no
 longer exist thanks to Don's massive overhaul.  For example, a big one  
 is that
 pointers now work.  What limitations that could potentially be removed  
 still
 do exist in CTFE as of 2.054?

- try/catch - intrinsics (bsr, bsf etc. ) this currently also means no Appender

Don has a patch for appender that allows it to work during CTFE: https://github.com/D-Programming-Language/phobos/pull/129 Actually, that was merged, prior to 2.054 release, may want to try appender again ;)
      - array.reserve

array.reserve is specific to the GC, and the GC isn't the same during compile time. Asking for this is like asking for GC.malloc. However, if there ever was a working D compiler written in D, these kinds of things could be done no problem. Reserve does seem like a useful thing to allow during CTFE. Of course, I could change reserve to simply do nothing during ctfe, which would make things "work", even though reserving wasn't actually happening...
      - foreach over tupple (aka static foreach)

Jul 13 2011
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 13.07.2011 16:43, Steven Schveighoffer wrote:
 On Wed, 13 Jul 2011 02:32:41 -0400, Dmitry Olshansky 
 <dmitry.olsh gmail.com> wrote:

 On 12.07.2011 18:22, dsimcha wrote:
 The documentation for CTFE is outdated and specifies limitations 
 that no
 longer exist thanks to Don's massive overhaul.  For example, a big 
 one is that
 pointers now work.  What limitations that could potentially be 
 removed still
 do exist in CTFE as of 2.054?

- try/catch - intrinsics (bsr, bsf etc. ) this currently also means no Appender

Don has a patch for appender that allows it to work during CTFE: https://github.com/D-Programming-Language/phobos/pull/129 Actually, that was merged, prior to 2.054 release, may want to try appender again ;)

And I thought I was on a bleeding edge dmd, apparently I'm too slow to pull these in time :)
      - array.reserve

array.reserve is specific to the GC, and the GC isn't the same during compile time. Asking for this is like asking for GC.malloc. However, if there ever was a working D compiler written in D, these kinds of things could be done no problem. Reserve does seem like a useful thing to allow during CTFE. Of course, I could change reserve to simply do nothing during ctfe, which would make things "work", even though reserving wasn't actually happening...

I'd say that would be an adequate workaround.
      - foreach over tupple (aka static foreach)


Ok, so of all above try/catch is the last big thing. -- Dmitry Olshansky
Jul 13 2011
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
dsimcha wrote:
 The documentation for CTFE is outdated and specifies limitations that no
 longer exist thanks to Don's massive overhaul.  For example, a big one is that
 pointers now work.  What limitations that could potentially be removed still
 do exist in CTFE as of 2.054?

I rewrote the documentation for CTFE, it's been in the docs on github for several weeks but apparently didn't get into the download??? (I went on holidays before the beta was released, so I wasn't able to check it).
Jul 20 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/20/2011 1:59 PM, Don wrote:
 I rewrote the documentation for CTFE, it's been in the docs on github for
 several weeks but apparently didn't get into the download???
 (I went on holidays before the beta was released, so I wasn't able to check
it).

I don't see it here? https://github.com/D-Programming-Language/d-programming-language.org/pulls
Jul 20 2011
prev sibling parent reply Don <nospam nospam.com> writes:
dsimcha wrote:
 The documentation for CTFE is outdated and specifies limitations that no
 longer exist thanks to Don's massive overhaul.  For example, a big one is that
 pointers now work.  What limitations that could potentially be removed still
 do exist in CTFE as of 2.054?

The updated CTFE documentation is here: http://d-programming-language.org/function.html
Jul 25 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Don:

 The updated CTFE documentation is here:
 http://d-programming-language.org/function.html

 3. the following statement types are not allowed:
 * with statements

I hope this 'with' limitation is temporary :-) ------------------------ Regarding that whole page: I think the section about purity doesn't say that __ctfe is allowed in pure functions. ------------------------
Cyclic functions (i.e. functions that wind up directly or indirectly calling
themselves) are inferred as being impure, throwing, and  system.<

I didn't know/remember this. Is this done to simplify the analysis? int fact(T)(in T n) { return n ? (n * fact(n-1)): 1; } void main() pure { auto x = fact(5); } ------------------------
Attribute inference is not done for other functions, even if the function body
is present.<

In D.learn I have shown an idea: to infer only the purity of functions called by templates, to allow more templates to be pure; and such inferred purity is seen by function templates only. Example: if a impure function sqr() is called by both an impure function template bar() and by a pure function foo(), the compiler raises an error in foo(), because sqr() is not pure, but compiles the pure main() because sqr() called by bar() is seen as pure :-) int sqr(in int x) { return x * x; } int foo(in int x) pure { // error, sqr is not tagged pure return sqr(x) + sqr(x); } int bar(T)(in T x) { return sqr(x) * sqr(x); } void main() pure { bar(1); // OK, sqr can be inferred as pure } But it seems a bit complex for the final programmer too (and maybe it needs a one level deeper purity inference). Bye, bearophile
Jul 25 2011