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
