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 <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
