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
