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

Pierre Talbot ptalbot at hyc.io
Tue Jan 28 15:21:04 PST 2014


On 01/28/2014 11:26 PM, Eric Reed wrote:
> Looks pretty reasonable to me at first glance.
> Out of curiosity, what's the rationale behind forbidding unsafe 
> functions/blocks?
>
In the reference manual we can read things such as: "Mutating an 
immutable value/reference, if it is not marked as non-freeze". This 
would be impossible at compile-time.
But I'm agree that we could relax this constraint and specify more 
precisely in which cases we disallow this.|||||
|
> On Tue, Jan 28, 2014 at 2:15 PM, Pierre Talbot <ptalbot at hyc.io 
> <mailto: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 <mailto:Rust-dev at mozilla.org>
>     https://mail.mozilla.org/listinfo/rust-dev
>
>



More information about the Rust-dev mailing list