Re: PointerWrapper Trait vs croe::ops::Deref

[Finn Behrens <me@kloenk.de>]

Howdy,

> On 9. May 2021, at 16:21, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
> 
> On Sun, May 9, 2021 at 12:25 PM Finn Behrens <me@kloenk.de> wrote:
>> 
>> Maybe we could also remove the result, as it would possible be an invariant, and never happen as the pointer should already be valid.
> 
> If it can fail, we cannot use `Deref` to begin with. So yeah, to make
> the examples equivalent, the first one should not return a `Result`.
> 
> Now, assuming it cannot fail, what I mentioned in the meeting is that
> with `Deref` all this compiles:
> 
> wrapper.deref().number
> (*wrapper).number
> wrapper.number
> 
> The question boils down to: do we want this shortcut or not?

I would not like to decide that on my own :-).
After thinking about it I think we don’t want that shortcut, as the other way give the same behaviour, but it is explicit.

> Having said that, I am not sure I understand the traits shown here.
> Isn't `PointerWrapper` meant only to save a `Box<T>` and similar types
> (which already implement `Deref` themselves etc.) as a pointer in a C
> data structure? (which is why `into_pointer()` consumes the object).
> 

All Pointers I’m wrapping are got from the C side. Either because there is a special malloc flag and some initialisation to the C struct, or as this is in a function call, and therefor the object is constructed out of my reach.
I usually do not consume the pointer, as I have to give the pointer to multiple function on the C side.

> In the examples shown, the new `get_pointer()` does not consume
> `self`; and `main()` creates a `Wrapper` using `from_pointer()`. But
> the idea is that you already have an object (constructed via other
> means), transform it into a raw pointer, and then later on
> re-construct the original object back from that pointer.
> 
> So `PointerWrapper` trait is like a `SavedAsPointer` trait, if you will.

Renaming to `SavedAsPointer` sounds great.

> 
> Cheers,
> Miguel

CU,
Finn