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

11–20 of 56 posts

Re: Rust: Box Is a Unique Type

#11

Post by landr0id »

>While we are many missing language features away from this being the case, the noalias case is also magic descended upon box itself, with no user code ever having access to it.

I'm not sure why the author thinks there's magic behind Box. Box is not a special case of `noalias`. Run this snippet with miri and you'll see the same issue: https://play.rust-lang.org/?version=stable&mode=debug&editio...

You don't see an assertion failure though because... dun dun dun it's UB.

`Box` _does_ have an expectation that its inner pointer is not aliased to another Box (even if used for readonly operations). See: https://github.com/rust-lang/miri/issues/1800#issuecomment-8...)

Re: Rust: Box Is a Unique Type

#12

Post by [deleted] »

landr0id wrote: post #11

>While we are many missing language features away from this being the case, the noalias case is also magic descended upon box itself, with no user code ever having access to it. I'm not sure why the author thinks there's magic behind Box. Box is not a special case of `noalias`. Run this snippet with miri and you'll see the same issue: https://play.rust-lang.org/?version=stable&mode=debug&editio... You don't see an as…

[deleted]

Re: Rust: Box Is a Unique Type

#13

Post by LegionMammal978 »

vlovich123 wrote: post #10

The biggest annoying magic I found with respect to Box (and other std containers like Rc) is that they’re the only ones capable of storing fat dyn pointers. You can’t construct a hybrid_rc::Rc like you can with Box/Rc. It’s annoying magic like that that bothers me. Another example is async lifetimes - it’s frequently hard to properly express the lifetime of a borrow resulting in choices of an unnecessary Box::pin, un…

> The biggest annoying magic I found with respect to Box (and other std containers like Rc) is that they’re the only ones capable of storing fat dyn pointers. You can’t construct a hybrid_rc::Rc like you can with Box/Rc.

It's perfectly possible to make a container capable of storing trait objects: just define the type parameter as . The main issue is that unlike Box/Rc, the compiler won't give you an automatic coercion from MyRc to MyRc, so you have to write a method to explicitly perform that cast. It just isn't common for many existing third-party containers to support !Sized objects, since it takes tedious unsafe code to manipulate them in memory.

Re: Rust: Box Is a Unique Type

#14

Post by andy_xor_andrew »

One of the biggest struggles I have (and others have, judging from Stack Overflow) is how to generically handle accepting types of Box, Rc, T, Pin, &T, &mut T, etc etc.

Of course you can write a function that is generic on > or something, but the moment you introduce function-coloring stuff like async, object safety, etc, things explode.

Re: Rust: Box Is a Unique Type

#15

Post by pylua »

andy_xor_andrew wrote: post #14

One of the biggest struggles I have (and others have, judging from Stack Overflow) is how to generically handle accepting types of Box , Rc , T, Pin , &T, &mut T, etc etc. Of course you can write a function that is generic on > or something, but the moment you introduce function-coloring stuff like async, object safety, etc, things explode.

Is that by design ? I am a novice at rust, but that is sort of how it feels. I could be missing something.

Re: Rust: Box Is a Unique Type

#16

Post by IshKebab »

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…

Miri can't detect all UB, so I think it's still sensible to reduce the chance of writing it in the first place.

Re: Rust: Box Is a Unique Type

#17

Post by gpm »

vlovich123 wrote: post #10

The biggest annoying magic I found with respect to Box (and other std containers like Rc) is that they’re the only ones capable of storing fat dyn pointers. You can’t construct a hybrid_rc::Rc like you can with Box/Rc. It’s annoying magic like that that bothers me. Another example is async lifetimes - it’s frequently hard to properly express the lifetime of a borrow resulting in choices of an unnecessary Box::pin, un…

> The biggest annoying magic I found with respect to Box (and other std containers like Rc) is that they’re the only ones capable of storing fat dyn pointers. You can’t construct a hybrid_rc::Rc like you can with Box/Rc.

Anything can store fat dyn pointers, they're just like any other type in that regards.

Constructing them for a specific trait is easy and possible on stable (e.g. adding a `as_debug(MyBox) -> MyBox` method).

Making it possible to construct them for any trait is special to the built in pointers... on stable. On nightly with unstable features it's possible (and easy) to make any smart pointer type do this.

Code examples:

https://play.rust-lang.org/?version=nightly&mode=debug&editi...

Re: Rust: Box Is a Unique Type

#18

Post by unstruktured »

andy_xor_andrew wrote: post #14

One of the biggest struggles I have (and others have, judging from Stack Overflow) is how to generically handle accepting types of Box , Rc , T, Pin , &T, &mut T, etc etc. Of course you can write a function that is generic on > or something, but the moment you introduce function-coloring stuff like async, object safety, etc, things explode.

macros can help with this if you can narrow down the traits you want to support.

https://doc.rust-lang.org/reference/macros.html

Re: Rust: Box Is a Unique Type

#19

Post by mmastrac »

IshKebab wrote: post #16
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…

Miri can't detect all UB, so I think it's still sensible to reduce the chance of writing it in the first place.

I'm not aware of any UB that can 1) be caused by unique pointer violations from Box and 2) are undetectable by Miri (assuming good code coverage), but I might be wrong about this.

Re: Rust: Box Is a Unique Type

#20

Post by vlovich123 »

LegionMammal978 wrote: post #13
vlovich123 wrote: post #10

The biggest annoying magic I found with respect to Box (and other std containers like Rc) is that they’re the only ones capable of storing fat dyn pointers. You can’t construct a hybrid_rc::Rc like you can with Box/Rc. It’s annoying magic like that that bothers me. Another example is async lifetimes - it’s frequently hard to properly express the lifetime of a borrow resulting in choices of an unnecessary Box::pin, un…

> The biggest annoying magic I found with respect to Box (and other std containers like Rc) is that they’re the only ones capable of storing fat dyn pointers. You can’t construct a hybrid_rc::Rc like you can with Box/Rc. It's perfectly possible to make a container capable of storing trait objects: just define the type parameter as . The main issue is that unlike Box/Rc, the compiler won't give you an automatic coerci…

Sorry - that's exactly what I meant. The automatic conversion from to .
Post reply on HN