[rust-dev] Compile-time function evaluation in Rust

Vladimir Lushnikov vladimir at slate-project.org
Tue Jan 28 16:40:17 PST 2014

CTFE would indeed be a very interesting thing to see an experiment on in

However, practically, what is the problem that CTFE solves that cannot be
solved by a hygienic macro system (or alternatively, a syntax extension
that has access to the AST)?

My experience with D's CTFE has been largely negative (though it was
several years and things may have changed), for a couple of reasons:

1. CTFE is hard to debug (D at the time didn't give very good error
messages in this area especially)
2. Turing completeness is not preventable (obvious but nevertheless because
of point 1 again difficult to find out where something has gone wrong)
3. String generation of program code (i.e. an unclean macro system) was
even more difficult to work with (I see this is not in the proposal, which
is great)

To me it just doesn't seem obvious Rust would need CTFE just as its macro
support is improving.


On Wed, Jan 29, 2014 at 12:18 AM, Kevin Ballard <kevin at sb.org> wrote:

> On Jan 28, 2014, at 4:01 PM, Pierre Talbot <ptalbot at hyc.io> wrote:
> > On 01/29/2014 12:45 AM, Kevin Ballard wrote:
> >> Yes, I was using #[ctfe] to mean something slightly different than you
> were. In my case, it meant "mark this function as eligible for CTFE, and
> impose all the CTFE restrictions". And it does fix the problem I mentioned,
> because #[ctfe] would be considered part of the function signature, not the
> function implementation. Everyone is already used to the idea that
> modifying the function signature may cause compiler errors at the call
> site. But the only example I can think of right now for when changing a
> function's _implementation_ causes call site compiler errors is when you're
> using C++ templates.
> >>
> >> Not only that, but with your approach, changing the implementation of
> one function could accidentally cause a whole host of other functions to
> become ineligible for CTFE. And the farther apart the actual source of the
> problem, and the resulting error, the harder it is to diagnose and fix such
> errors.
> >>
> >> That said, I was not aware that D already takes this approach, of
> allowing CTFE by default. I'm curious how it works for them, and how they
> handle these problems.
> >>
> >> -Kevin
> > They do not allow it by default, they rely on the context (as I also do)
> to activate it. If a function is designed with CTFE requirements, these
> might not change much over the time (speculation). I mean, did you ever
> re-factorize a function code to add unsafe, extern or I/O statements? I
> have the feeling that it doesn't arrive so often. But it's just an
> intuition...
> Sure. Unsafe is sometimes used to optimize code for performance that was
> otherwise safe.
> I could write a function intended for CTFE, using a perfectly harmless API
> (say, std::vec), and then have an update to the perfectly harmless API
> introduce unsafe code for the purposes of optimization (as has happened in
> std::vec in the past), and suddenly my function is no longer CTFE-eligible.
> -Kevin
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140129/0d1b6212/attachment.html>

More information about the Rust-dev mailing list