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

[Paolo Bonzini <pbonzini@redhat.com>]

On 29/09/20 19:55, Marc-André Lureau wrote:
> My understanding of what you propose is:
> - ForeignConvert::with_foreign
> - FromForeign::from_foreign (with implied into_native)
> And:
> - ForeignConvert::as_foreign (with the BorrowedPointer/stash-like)
> - ToForeign::to_foreign + ForeignConvert::as_foreign_mut (which seems
> wrongly designed in your proposal and unnecessary for now)

Might well be, but how is it wrong?  (I'd like to improve).

> 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

* as_: a cheap conversion to something, it's cheap because it reuses the
lifetime (and therefore takes no ownership).  Think Option::as_ref.

* 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_).

* into_: a conversion that consumes the receiver

It may well be over the top.

> 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?

> Finally, I thought you introduced some differences with the stash
> design, but in fact I can see that ForeignConvert::Storage works just
> the way as ToPtr::Storage. So composition should be similar. Only your
> example code is more repetitive as it doesn't indirectly refer to the
> trait Storage the same way as glib-rs does (via <T as ToPtr>::Storage).

Yes, that's the main difference.  I removed Storage because I didn't
want to force any trait on BorrowedPointer's second type argument.  It
seemed like a generic concept to me.

The other difference is that Stash is a tuple while BorrowedPointer is a
struct and has methods to access it.  Stash seems very ugly to use.

> I am not making any conclusions yet, but I am not exactly happily going
> to switch to your proposal yet :)

Sure, no problem.

Paolo