Info
This post is auto-generated from RSS feed The Rust Programming Language Forum - Latest topics. Source: Practice: Steps happening in deref coercion
I've learnt part of the topic of dereferencing. As a self-made exercise I tried to follow the steps of dereferencing going from &Box<i32>
(one or nested) to &i32
.
Here I simply expose my reasoning to see whether there are important corrections to be made.
The snippet is:
fn main() {
let bbox:Box<i32> = Box::new(5);
fn a (b:&i32){
println!("{}",b);
}
a(&bbox); // we expect that &Box can coerce to &i32
}
Having read Deref
coercions in the book and the reference the process is basically applying .deref()
until the obtained type fits the explicit type.
It seems the procedure โfor this random case I used as an exerciseโ would be:
&bbox=&Box<i32>
which is an &T
.
&-type
must implement Deref
, so we can do things like *&T
.&T
will do the standard method search and find that &Box
is accepted by deref(&self)
so it stops there (otherwise it would try with &&Box, &mut &Box, Box,...
)&bbox.deref()
to get &T
which should be something like &**
if I understand correctly. (first dereferences &self
and second one gets to the data T
.)i32
this would be (&**(&**))
repeatedly.&T=&i32
.6 posts - 3 participants
๐ท๏ธ rust_feed