[rust-dev] Compile-time function evaluation in Rust
ecreed at cs.washington.edu
Tue Jan 28 15:34:32 PST 2014
That's what I figured. Forbidding unsafe is definitely a good way to keep
things simple starting out. Compile time evaluation can always be extended
On Tue, Jan 28, 2014 at 3:21 PM, Pierre Talbot <ptalbot at hyc.io> wrote:
> 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
>> 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:
>> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rust-dev