Re: [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now)

[Paolo Bonzini <pbonzini@redhat.com>]

On 30/09/20 11:15, Marc-André Lureau wrote:
> Why BorrowedMutPointer provides both *const P and *mut P ? The *const P
> conversion seems overlapping with BorrowedPointer.

"&mut T" implements Borrow so it seemed obvious to have as_ptr in
BorrowedMutPointer too.  Though I certainly should implement Borrow in
BorrowedMutPointer.

>     > I don't have your head, so I find it hard to remember & work with.
>     It> uses all possible prefixes: with_, from_, as_, as_mut, to_, and
>     into_.
>     > That just blows my mind, sorry :)
> 
>     Ahah I don't have your head either!  The idea anyway is to reuse
>     prefixes that are common in Rust code:
> 
>     * with_: a constructor that uses something to build a type (think
>     Vec::with_capacity) and therefore takes ownership
> 
> ForeignConvert::with_foreign (const *P -> T) doesn't take ownership.
> 
> The Rust reference for this kind of conversion is CStr::from_ptr.

Ok, I'll take a look.

>     * as_: a cheap conversion to something, it's cheap because it reuses the
>     lifetime (and therefore takes no ownership).  Think Option::as_ref.
> 
> as_ shouldn't create any object, and is thus unsuitable for a general
> rs<->sys conversion function (any).

as_foreign function does not create anything, it reuses the storage to
provide a pointer.  It seems similar to as_slice for example.

>     * from_/to_: a copying and possibly expensive conversion (that you have
>     to write the code for).  Because it's copying, it doesn't consume the
>     argument (for from_) or self (for to_).
> 
> and that's what glib-rs uses (and CStr).

Sort of, I found the none/full suffixes not really idiomatic for Rust.

>     * into_: a conversion that consumes the receiver
> 
> That's not used by glib afaik, but we should be able to introduce it for
> "mut *P -> T", it's not incompatible with FromPtrFull::from_full.

Right.  It's just a different way to write the same thing.  Usually it
is a bit more concise because it allows more type inference.

>     > Then, I don't understand why ForeignConvert should hold both the
>     > "const *P -> T" and "&T -> const *P" conversions. Except the
>     > common types, what's the relation between the two?
> 
>     Maybe I'm wrong, but why would you need just one?
> 
> No I mean they could be on different traits. One could be implemented
> without the other. Or else I don't understand why the other conversion
> functions would not be in that trait too.

The other conversion functions require taking ownership, and I was not
sure if it would always be possible to do so.  For no-ownership-taken
conversions, however, it seemed to me that you'd rarely be unable to
implement one of the two directions.  I might be wrong.

In general though I agree that the changes are mostly cosmetic.

Paolo