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
mention it):
* 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?
Cheers,
Josh
On 28 January 2014 14:15, Pierre Talbot <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
