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

Pierre Talbot ptalbot at hyc.io
Wed Jan 29 01:19:08 PST 2014


On 01/29/2014 01:39 AM, Brendan Zabarauskas wrote:
> On 29 Jan 2014, at 9:15 am, Pierre Talbot <ptalbot at hyc.io> wrote:
>
>> 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.
>
> This sounds very much like D’s `pure` keyword. http://dlang.org/function.html#pure-functions
>
>  From the website:
>
>> Pure Functions
>> --------------
>>
>> Pure functions are functions which cannot access global or static, mutable state save through their arguments. This can enable optimizations based on the fact that a pure function is guaranteed to mutate nothing which isn't passed to it, and in cases where the compiler can guarantee that a pure function cannot alter its arguments, it can enable full, functional purity (i.e. the guarantee that the function will always return the same result for the same arguments). To that end, a pure function:
>>
>> - does not read or write any global or static mutable state
>> - cannot call functions that are not pure
>> - can override an impure function, but an impure function cannot override a pure one
>> - is covariant with an impure function
>> - cannot perform I/O
>>
>> As a concession to practicality, a pure function can:
>>
>> - allocate memory via a NewExpression
>> - terminate the program
>> - read and write the floating point exception flags
>> - read and write the floating point mode flags, as long as those flags are restored to their initial state upon function entry
>> - perform impure operations in statements that are in a ConditionalStatement controlled by a DebugCondition.
>>
>> A pure function can throw exceptions.
> CTFE would be extremely welcome for improving Rust’s compile time code generation capabilities. This is important both practically and also for closing the gap between us and D or C++. It could allow, for example, numeric operators to be overloaded in the std whilst still being able to be used at compile time. Casts could also be implemented in-library. I’m sure there are even better examples though.
>
> ~Brendan
Hi,

 From my proposal:

2.3 Relation with pure function

A pure function is a function that is free of side-effects, you can call 
a pure function any
number of time with the same set of inputs and be sure the results will 
be identical.
An observation is that if a function meets the requirements of CTFE it 
must be a pure
function, but a pure function doesn’t necessarily meet the requirements 
of CTFE. It
mostly depends on the language, for example, in Rust, a pure function 
can contain
unsafe blocks but the CTFE requirements doesn’t allow that.

I add: a pure function can call extern code and diverges, so the pure 
requirements are a subset of the CTFE requirements.

Pierre


More information about the Rust-dev mailing list