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

Pierre Talbot ptalbot at hyc.io
Tue Jan 28 15:16:22 PST 2014

On 01/28/2014 11:24 PM, Kevin Ballard wrote:
> 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
I understand your point of view but adding #[ctfe] doesn't solve the 
problem either, the library designer could remove this annotation, isn't 
it? I didn't precise it, but I gave a different semantic to #[ctfe] than 
what you understood. Let me rephrase it:

* #[ctfe] hints the compiler that performing CTFE outside of the contexts (as specified) is safe. It means that for any input this function will terminate [in a reasonable amount of time and memory].

We should keep in mind the drawbacks of the constexpr semantic:

1. Force the library designer to think about CTFE, the user might be in 
a better position since he knows well which parameters he'll give to 
this function.
2. Annotate functions means more maintenance, more changes and more 
errors. Moreover, the C++11 constexpr only allow a subset of the 
language, which is practical for the compiler implementor but not for 
the library designer. In D, they specify when a function is *not* eligible.

Thanks for comments!
> 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