That's what I figured. Forbidding unsafe is definitely a good way to keep
things simple starting out. Compile time evaluation can always be extended
later on.
On Tue, Jan 28, 2014 at 3:21 PM, Pierre Talbot <ptal...@hyc.io> wrote:
> 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 <ptal...@hyc.io <mailto:
>> 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 <mailto: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
