[rust-dev] Compile-time function evaluation in Rust
ptalbot at hyc.io
Tue Jan 28 15:41:53 PST 2014
The way it is implemented in Rust is by using the libc, but the
requirement #6 says we can't call external function, so implicitly the
problem is solved. I'm agree that it isn't formal, but I can't come up
with a better solution for now.
You made me think of another requirements (so basic that I forgot to
* A function is eligible for CTFE if every function calls inside this
function are themselves eligible.
On 01/28/2014 11:27 PM, Josh Matthews wrote:
> Out of that list of requirements, #5 (doesn’t perform I/O actions) is
> the one that strikes me as least well-defined. Could you elaborate on
> how you would enforce it?
> On 28 January 2014 14:15, Pierre Talbot <ptalbot at hyc.io
> <mailto:ptalbot at hyc.io>> wrote:
> The Mozilla foundation proposes research internships  and the
> CTFE optimization in the Rust compiler seems to be a really
> exciting project. I wrote a proposal  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.
> Pierre Talbot
>  https://careers.mozilla.org/en-US/position/oZO7XfwB
>  http://hyc.io/rust-ctfe-proposal.pdf
> Rust-dev mailing list
> Rust-dev at mozilla.org <mailto:Rust-dev at mozilla.org>
> Rust-dev mailing list
> Rust-dev at mozilla.org
More information about the Rust-dev