#rust-lang

centril, nmatsakis, aturon, woboats, Gankro: so I was trying to sketch some dependent stuff using Rust's lifetime generativity and associated type normalization got me :( - would GAT make this work? (I don't know how to check this in chalk) https://play.rust-lang.org/?gist=7f5fe921f8943f...

although I'm not even sure it's sound this way

I might need to make those Pi impls not pattern match out the lifetime

this still doesn't normalize despite the impls being even more generic https://play.rust-lang.org/?gist=b012a5bbc002d8...

now with no bounds on the impls https://play.rust-lang.org/?gist=6f7ff52f7156f6...

this really seems like a bug, but I'm not sure I can reduce it easily

it's really funny how inference appears to break down when trying to emulate some form of dependent type checking in Rust

in https://github.com/rust-lang/rust/issues/24111#..., what does eddyb mean by "dynamically non-const"?

alercah: as in, whether unsafe { *ptr += 1; } can be evaluated at compile-time can dependent on the value of ptr

if ptr is a cast &mut x pointing to a local variable, that's fine

is ptr points to global data or is an integer address, it's not fine

ah right

That didn't get much attention on the discussions there; what is the plan to deal with those things? Is dynamic const-ness the actal way it's being handled?

(I hyperfocused on the const fn trait stuff and I'm writing up thoughts in hopes they're useful and want to make sure I account for that)

eddyb: you can get value-depenedence in safe Rust too, with && or ||, if you deign to allow false && rand() to be constant

alercah: I think the plan is to fully statically check safe code, and "dynamically" (i.e. during miri evaluation) check unsafe code. we also need to specify what const unsafe code can do when called at runtime, which if we specify as "nothing more than at compile-time", then we get `const fn` == `pure fn`

but that's not something we can check, only something we can put in the unsafe code guidelines etc.

hm, right

The reason this requires unsafe code is that there's no way for const safe code to get a mutable reference to anything outside the current const evaluation, correct?

actually wait

isn't any dereference bad enough?

It could refer to a static with interior mutability

which might not always yield the same value

Such dereferences result in errors

ok, trying that the actual thing is that const fns can't refer to statics, which makes sense. but that would mean that in eddyb's example, it couldn't actually be a global, right/

hang on

alercah: const fns should be able to refer to statics

there were some limitations before because the pre-miri implementation would do the wrong thing for *&STATIC

but now it should all be fixed and soon a ton of limitations will be lifted

ah

Isn't that a problem, then

why?

If the static has interior mutability, then it wouldn't be pure

reading statics is fine

alercah: purity isn't about &T vs &mut T

or interior mutability

At compile-time, yes, but at run-time the value could change

you mean like Cell::set?

oh, I guess interior mutability could just not be const

or like an atomic increment

so the const fn would have to have no way of observing the interiorly mutable value

ok

alercah: the function performing the mutation (with unsafe code) could only be marked const fn if we decide that the potential of allowing it at runtime is fine

eddyb: I wasn't thinking of mutating at runtime

you have to go through UnsafeCell::get which returns a raw pointer

right, ok

alercah: at compile-time you can't mutate non-locals anyway

even through indirection

yeah

I was thinking of the case where a const fn read a value that was subject to interior mutability

and then it was mutated at runtime

that's fine

why?

I mean the interior value here

that's the same as a function copying the T from a &mut T

not the value containing it

Reading mutable statics is allowed in const fns?

soon it will be, yeah

But that can make them non-pure, can't it?

there's no side-effect

oh you mean strict referential transparency hmmmm

oh, I'm thinking of pure too narrowly here, right

so something like DerefPure

if you regard referenced statics as an input, then they are pure

where you want the behavior to not depend on anything other than arguments

yeah

frick

all of this makes me not want to have a strong purity concept in Rust

RalfJ: ^^

it's starting to seem orthogonal to const fn

or, rather, input side effects vs output side effects...

at compile-time reading statics is *not* an input side effect because the value can't change

bbl

eddyb: when you're back, unsafe { *ref } is potentially problematic on its own if it's an integer address, right?

alercah: It's is not allowed. There's no global address space to get the memory from

Zoxc: I think the point is that you may not know ahead of time

right

that someone would pass in an integer pointer

(assuming you have a raw pointer and not a reference)

I was just checking that the assignment is not necessary

in your example above

I guess RefCell::borrow won't be allowed on statics, since it mutates memory

You mean consts?

It just needs to be non-const