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 <[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
