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

Eric Reed 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
later on.


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


More information about the Rust-dev mailing list