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

Eric Reed ecreed at cs.washington.edu
Tue Jan 28 14:26:25 PST 2014


Looks pretty reasonable to me at first glance.
Out of curiosity, what's the rationale behind forbidding unsafe
functions/blocks?


On Tue, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140128/49e226e7/attachment.html>


More information about the Rust-dev mailing list