CTFE would indeed be a very interesting thing to see an experiment on in Rust.
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. Vladimir On Wed, Jan 29, 2014 at 12:18 AM, Kevin Ballard <[email protected]> wrote: > On Jan 28, 2014, at 4:01 PM, Pierre Talbot <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
