3 ms·

This maybe calls for a way to tell the compiler that we don't care what value this object has, but we promise it does already have some concrete value. As writ

This maybe calls for a way to tell the compiler that we don't care what value this object has, but we promise it does already have some concrete value. As written this can't work, but once the compiler understands what's going on it seems fine. In Rust I'd imagine this as a method on MaybeUninit<T> the type which might be a T but maybe not yet. It's possible we can just assume_init() today where T is something like a byte but if it's unclear, a method which expresses our intent to get an unspecified value is better than just saying well, maybe you can assume_init() but we're not sure if that means what you intended.

iudqnolq 3y ago
Problem is an uninit value is unstable. The compiler could be using it to store something else, and could change what it's storing at different times. You need a freeze operation to say "I don't care what that this is, but it should have one value". https://www.ralfj.de/blog/2019/07/14/uninit.html https://www.ralfj.de/blog/2019/07/14/uninit.html
- tialaramex 3y ago
  Right, I have seen that post but I didn't end up remembering the use of "freeze" to name this operation. I'd be fine if it was named freeze, labelled unsafe and specifically called out in Safety as requiring that all bit patterns for T are valid representations of T which I think meets the requirement, but it sounds like this can't be done (easily?) without help from LLVM
raphlinus 3y ago
Right, in relatively recent versions of LLVM, there is a "freeze" operation. Making it available to programmers, possibly as a method off MaybeUninit, would potentially be useful. The safety overlaps that of "safe transmute" (and ecosystem crates such as bytemuck that provide that). The Pod trait[1] probably establishes the invariants so that freeze on uninitialized memory is safe. I imagine the details are tricky (my understanding is that "freeze" took a long time to land in LLVM), but that there's no fundamental reason it can't be done. But I also imagine there are a lot higher priorities; the use case in this blog is pretty niche. There's more discussion in this thread: [2] [1]: https://docs.rs/bytemuck/latest/bytemuck/trait.Pod.html https://docs.rs/bytemuck/latest/bytemuck/trait.Pod.html [2]: https://internals.rust-lang.org/t/freeze-maybeuninit-t-maybeuninit-t-for-masked-reads/17188 https://internals.rust-lang.org/t/freeze-maybeuninit-t-maybe...
- tialaramex 3y ago
  I definitely care more about growing what is possible, and specifically what can be written correctly than about the - perhaps more sensible - goal of making possible things easier. So that's a place where my priorities aren't Rust's priorities. My preferences absolutely can lead to the Turing Tarpit. Reading for after work thanks for links

iudqnolq 3y ago

Problem is an uninit value is unstable. The compiler could be using it to store something else, and could change what it's storing at different times. You need a freeze operation to say "I don't care what that this is, but it should have one value". https://www.ralfj.de/blog/2019/07/14/uninit.html https://www.ralfj.de/blog/2019/07/14/uninit.html

tialaramex 3y ago
Right, I have seen that post but I didn't end up remembering the use of "freeze" to name this operation. I'd be fine if it was named freeze, labelled unsafe and specifically called out in Safety as requiring that all bit patterns for T are valid representations of T which I think meets the requirement, but it sounds like this can't be done (easily?) without help from LLVM

raphlinus 3y ago

Right, in relatively recent versions of LLVM, there is a "freeze" operation. Making it available to programmers, possibly as a method off MaybeUninit, would potentially be useful. The safety overlaps that of "safe transmute" (and ecosystem crates such as bytemuck that provide that). The Pod trait[1] probably establishes the invariants so that freeze on uninitialized memory is safe. I imagine the details are tricky (my understanding is that "freeze" took a long time to land in LLVM), but that there's no fundamental reason it can't be done. But I also imagine there are a lot higher priorities; the use case in this blog is pretty niche. There's more discussion in this thread: [2] [1]: https://docs.rs/bytemuck/latest/bytemuck/trait.Pod.html https://docs.rs/bytemuck/latest/bytemuck/trait.Pod.html [2]: https://internals.rust-lang.org/t/freeze-maybeuninit-t-maybeuninit-t-for-masked-reads/17188 https://internals.rust-lang.org/t/freeze-maybeuninit-t-maybe...

tialaramex 3y ago
I definitely care more about growing what is possible, and specifically what can be written correctly than about the - perhaps more sensible - goal of making possible things easier. So that's a place where my priorities aren't Rust's priorities. My preferences absolutely can lead to the Turing Tarpit. Reading for after work thanks for links