Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust: Box Is a Unique Type

blog.nilstrieb.dev

Post reply on HN
Print view View original

51–56 of 56 posts

Re: Rust: Box Is a Unique Type

#51

Post by simonask »

vlovich123 wrote: post #45
Rusky wrote: post #28

Earlier quoted context omitted.

The problem with this, as the article argues in detail, is that it leaves a hole in functionality that people need but offers no clear benefit in return. A movable owning pointer that exposes its pointer-ness in its semantics is a useful tool when you're doing lower-level, sometimes-unsafe stuff with memory layout. The author points out that, because Box does not currently provide this functionality, there are crates…

I think the better approach would be to standardize some kind of feature that lets you annotate variables as "not noalias" so that Rust knows to elide the noalias for those values. That's a much more generic way to solve the ecosystem problem without changing Box semantics or introducing one off types. That being said, there's already a solution in the ecosystem which is to not use aliased pointers after giving the p…

For the record, Rust does have a "not noalias" builtin magic type in the standard library: UnsafeCell.

https://doc.rust-lang.org/stable/std/cell/struct.UnsafeCell....

Re: Rust: Box Is a Unique Type

#52

Post by bbatha »

zamalek wrote: post #23
mmastrac wrote: post #9

I strongly disagree with this article. Perhaps in the days before Miri it might have made sense, but it's pretty trivial right now to discover UB in unsafe code with a simple `cargo +nightly miri test` run. It feels like the Rust team is a bit wary of introducing other optimizations for fear of breaking unsafe code that has lurking UB, but it's better to start working on fixing these problems _now_ rather than get st…

This is why I firmly argue (and pretend) that references are not pointers. "References are pointers" results in the belief that references will behave like C pointers and results in things like this article. At best they are a cousin of pointers. I consider the fact that they are pointers an implementation detail, just like Box is a value with 'static samantics.

I really wish rust didn't make the guarantee that references are pointers, if I ever made a Rust 2.0 I wouldn't make this guarantee. It would make the `Copy` type less needed and help with extra `&&&` coming up in generics. It could make references to packed and unaligned bits safe. It could also support offset-references for self types.

Re: Rust: Box Is a Unique Type

#53

Post by LegionMammal978 »

simonask wrote: post #51
vlovich123 wrote: post #45

Earlier quoted context omitted.

I think the better approach would be to standardize some kind of feature that lets you annotate variables as "not noalias" so that Rust knows to elide the noalias for those values. That's a much more generic way to solve the ecosystem problem without changing Box semantics or introducing one off types. That being said, there's already a solution in the ecosystem which is to not use aliased pointers after giving the p…

For the record, Rust does have a "not noalias" builtin magic type in the standard library: UnsafeCell. https://doc.rust-lang.org/stable/std/cell/struct.UnsafeCell....

No, UnsafeCell doesn't change any rules around non-aliasing for &mut/Box. (E.g., if you move a Box>, it will still invalidate any pointers to the data.) All it does is change the rules around immutability for & references. &T is "not noalias" regardless of UnsafeCell, but it's immutable in its absence.

Meanwhile, there is a magic "not noalias" mechanism currently recognized by Miri, in the form of !Unpin types. But this is considered a temporary hack to keep it from complaining about pinned futures that reference their own fields, in the absence of an actual language feature. Also, it only applies to accessing values through unique references, not to moving or writing to them by their binding.

Re: Rust: Box Is a Unique Type

#54

Post by Rusky »

LegionMammal978 wrote: post #53
simonask wrote: post #51

Earlier quoted context omitted.

For the record, Rust does have a "not noalias" builtin magic type in the standard library: UnsafeCell. https://doc.rust-lang.org/stable/std/cell/struct.UnsafeCell....

No, UnsafeCell doesn't change any rules around non-aliasing for &mut/Box. (E.g., if you move a Box >, it will still invalidate any pointers to the data.) All it does is change the rules around immutability for & references. &T is "not noalias" regardless of UnsafeCell, but it's immutable in its absence. Meanwhile, there is a magic "not noalias" mechanism currently recognized by Miri, in the form of !Unpin types. But…

&T is noalias - while there may be aliases none can write, which is the important thing - without UnsafeCell, and &UnsafeCell loses noalias for that reason.

Re: Rust: Box Is a Unique Type

#55

Post by workingjubilee »

mmastrac wrote: post #9

I strongly disagree with this article. Perhaps in the days before Miri it might have made sense, but it's pretty trivial right now to discover UB in unsafe code with a simple `cargo +nightly miri test` run. It feels like the Rust team is a bit wary of introducing other optimizations for fear of breaking unsafe code that has lurking UB, but it's better to start working on fixing these problems _now_ rather than get st…

what would "stabilize" mean when the opsem model that miri obeys continues to change?
Post reply on HN