It sounds like you're proposing that arbitrary functions may be eligible for
CTFE if they happen to meet all the requirements, without any special
annotations. This seems like a bad idea to me. I understand why it's
attractive, but it means that seemingly harmless changes to a function's
implementation (but not its signature) can cause compiler errors in other
modules, or even other crates if the AST for the function happens to be made
extern.
A more conservative approach would be to require the #[ctfe] annotation, which
then imposes all the given restrictions on the function. The downside is such a
function then is restricted to only calling other CTFE functions, so we'd have
to go in to the standard libraries and add this annotation whenever we think
it's both useful and possible.
This approach mirrors the approach being used by C++11/C++14.
-Kevin
On Jan 28, 2014, at 2:15 PM, Pierre Talbot <ptal...@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@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
