4 ms·

> What decides whether the caller still has something is whether you passed it by reference. I was referring to the `Box<dyn Trait>` one, as I'm at least 90% s

by a1369209993 4y ago

> What decides whether the caller still has something is whether you passed it by reference. I was referring to the `Box<dyn Trait>` one, as I'm at least 90% sure `Box<X>` passes a owned, dynamically-allocated X by reference (ie, Box<X> is a pointer to X).

tialaramex 4y ago
A Box<dyn Bird> is some sort of Bird on the heap. But if I pass a Box<Goose> to a function which wants a Box<dyn Bird>, then my call moves the Box<Goose> into the function, I don't still have that Goose, it's gone, I hope the function takes good care of it. If the function only wanted a reference to it, that would be &Box<dyn Bird> and then I wouldn't give up ownership by passing it to the function. But that's also a very strange thing to ask for, since we can instead pass a reference to a Bird, no need to Box it.
- a1369209993 4y ago
  > A Box<dyn Bird> is some sort of Bird on the heap. No, a Box<dyn Bird> is a pointer to some sort of Bird on the heap. Unless Rust has wildly changed how it implements function calls/stack frames, local variables are stored on the stack. A pointer is a reference to the thing it points to (in sense used in the phrase "pass by reference"). > then my call moves the Box<Goose> into the function, I don't still have that Goose Yes: you passed a Box<Goose> by value, you passed the Goose it points to by reference, and you transfered ownership of both.
  - tialaramex 4y ago
    I think what got confused here is just the nomenclature? In particular the use of "reference" to mean what we get when we borrow something in Rust, and its use to mean the address of something as part of a calling convention. > are you promising to deallocate and otherwise clean up the object when you're done with it, versus are you promising that the caller can keep using it after you return. Whether I ask for a Goose or a Box<Goose>, it's mine now. The caller no longer has it, it's not just that they shouldn't use it, they can't, the compiler won't let them. Since it's mine, it is now my responsibility as owner either clean up, give it to somebody else or explicitly leak() it. Rust doesn't promise how exactly this is implemented, and it is likely to be different for an object of 4 bytes than for an object of 400 bytes.

tialaramex 4y ago

A Box<dyn Bird> is some sort of Bird on the heap. But if I pass a Box<Goose> to a function which wants a Box<dyn Bird>, then my call moves the Box<Goose> into the function, I don't still have that Goose, it's gone, I hope the function takes good care of it. If the function only wanted a reference to it, that would be &Box<dyn Bird> and then I wouldn't give up ownership by passing it to the function. But that's also a very strange thing to ask for, since we can instead pass a reference to a Bird, no need to Box it.

a1369209993 4y ago
> A Box<dyn Bird> is some sort of Bird on the heap. No, a Box<dyn Bird> is a pointer to some sort of Bird on the heap. Unless Rust has wildly changed how it implements function calls/stack frames, local variables are stored on the stack. A pointer is a reference to the thing it points to (in sense used in the phrase "pass by reference"). > then my call moves the Box<Goose> into the function, I don't still have that Goose Yes: you passed a Box<Goose> by value, you passed the Goose it points to by reference, and you transfered ownership of both.
- tialaramex 4y ago
  I think what got confused here is just the nomenclature? In particular the use of "reference" to mean what we get when we borrow something in Rust, and its use to mean the address of something as part of a calling convention. > are you promising to deallocate and otherwise clean up the object when you're done with it, versus are you promising that the caller can keep using it after you return. Whether I ask for a Goose or a Box<Goose>, it's mine now. The caller no longer has it, it's not just that they shouldn't use it, they can't, the compiler won't let them. Since it's mine, it is now my responsibility as owner either clean up, give it to somebody else or explicitly leak() it. Rust doesn't promise how exactly this is implemented, and it is likely to be different for an object of 4 bytes than for an object of 400 bytes.