On 01/29/2014 01:39 AM, Brendan Zabarauskas wrote:
On 29 Jan 2014, at 9:15 am, Pierre Talbot <[email protected]> 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
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
