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

Kevin Ballard kevin at sb.org
Tue Jan 28 14:24:56 PST 2014


It sounds like you're proposing that arbitrary functions may be eligible for CTFE if they happen to meet all the requirements, without any special annotations. This seems like a bad idea to me. I understand why it's attractive, but it means that seemingly harmless changes to a function's implementation (but not its signature) can cause compiler errors in other modules, or even other crates if the AST for the function happens to be made extern.

A more conservative approach would be to require the #[ctfe] annotation, which then imposes all the given restrictions on the function. The downside is such a function then is restricted to only calling other CTFE functions, so we'd have to go in to the standard libraries and add this annotation whenever we think it's both useful and possible.

This approach mirrors the approach being used by C++11/C++14.

-Kevin

On Jan 28, 2014, at 2:15 PM, Pierre Talbot <ptalbot at hyc.io> wrote:

> Hi,
> 
> The Mozilla foundation proposes research internships [1] and the CTFE optimization in the Rust compiler seems to be a really exciting project. I wrote a proposal [2] that I'll send with my application and so I'd like to share it with you and discuss about bringing CTFE inside Rust.
> 
> Here a non-exhaustive summary of key points in my proposal.
> 
> First of all, we need to establish when CTFE is triggered, I found two contexts (denoted as a hole []):
> 
> * Inside a immutable static variable ("static" ident ’:’ type ’=’ [] ’;’).
> * In a vector expression (’[’ expr ’,’ ".." [] ’]’).
> 
> Next in a similar way than with "inline attributes" we might want to add these new attributes:
> 
> * #[ctfe] hints the compiler to perform CTFE.
> * #[ctfe(always)] asks the compiler to always perform CTFE resulting in a
> compiler error if it’s impossible.
> * #[ctfe(never)] asks the compiler to never perform CTFE resulting in a compiler
> error if this function is called in a CTFE context.
> 
> The rational behind this is that some functions might want to disallow CTFE, for example if they manipulate machine-dependent data (such as playing with endianness). Some might want to be designed only for compile-time and so we want to disable run-time execution. Finally others might hints the compiler to "try to optimize whenever you can", of course if the function contains infinite loop for some input, the compilation might not terminate.
> 
> I propose some requirements on function eligible for CTFE (see the proposal for references to the Rust manual):
> 
> 1. Its parameters are evaluable at compile-time.
> 2. It isn’t a diverging function.
> 3. It isn’t an unsafe function.
> 4. It doesn’t contain unsafe block.
> 5. It doesn’t perform I/O actions.
> 6. The function source code is available to the compiler. It mustn’t be in an external
> block, however it can be an extern function.
> 
> In this proposal, you'll also find a pseudo-coded algorithm, related work (in D and C++), and much more :-)
> 
> If you have any suggestions or corrections, do not hesitate. Also, feel free to ask questions.
> 
> Regards,
> Pierre Talbot
> 
> [1] https://careers.mozilla.org/en-US/position/oZO7XfwB
> [2] http://hyc.io/rust-ctfe-proposal.pdf
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev



More information about the Rust-dev mailing list