Oli Scherer comments

Results 727 comments of


                                            Oli Scherer

const fns cannot have fn pointer arguments that take mutable references, even if they aren't called

maybe we should just start allowing mutable references but not dereferencing them ^^

const fns cannot have fn pointer arguments that take mutable references, even if they aren't called

Immutable references to interior mut data are checked the same way. About a month ago @amanjeev was trying to replicate and add tests for the issues we had around mutable...

Must a `const fn` behave exactly the same at runtime as at compile-time?

So.. if we have a `const F: f32 = A + B;` and at runtime a `let f: f32 = A + black_box(B);`, then it is not necessary for `F.to_bits()...

Must a `const fn` behave exactly the same at runtime as at compile-time?

> Why that? I think it would work just as well. Unless of course all operations are non-deterministic, then this would be equivalent to ruling out FP entirely. What I...

Must a `const fn` behave exactly the same at runtime as at compile-time?

Even if we forbid floats forever in `const fn`, I think that `const fn foo(a: T, b: T) -> T::Output { a + b }` will become legal at some...

Must a `const fn` behave exactly the same at runtime as at compile-time?

Yes, my worry was that even without `impl const Add for f32`, we'll be able to call this generic const fn at runtime with float arguments and then (even if...

Must a `const fn` behave exactly the same at runtime as at compile-time?

The expense in CPU and memory is likely irrelevant. The heaviness of that approach is in the complexity of such an implementation. Everything in const eval needs to support abstract...

Must a `const fn` behave exactly the same at runtime as at compile-time?

it's not the computations themselves that are the complexity problem, it is the fact that every operation that doesn't even care about floats can now encounter a float. Without abstract...

Must a `const fn` behave exactly the same at runtime as at compile-time?

> @oli-obk would you mind updating the question in the OP here? It conflates CTFE and const propagation, as I pointed out in my first comment. There's already enough people...

Must a `const fn` behave exactly the same at runtime as at compile-time?

That's actually not a bad idea. We can start out by just forbidding NaNs in the final value of a constant, just like we forbid pointers in the final value...