Smart pointer which owns its target

[jbe]

Some more:

@CAD97

@jbe

It seems you're focused on Deref for the ergonomics of deref coercion […]

Why do I want deref coercion? Because if I work solely with references, deref works too!

And if you're working with Borrow<T> (i.e. the standard trait for a type which can be used as-ref like T ^[1]), you don't have deref coersion.

For the other readers of this thread: Yeah, that's what I was pointing out here:

@jbe

@CAD97

It seems you're focused on Deref for the ergonomics of deref coercion […]

Why do I want deref coercion? Because if I work solely with references, deref works too! If I work with Cow, then deref works also. If I always return an owned value (without wrapper), then deref doesn't work but I don't need it either. So yes, this is about ergonomics!

Following your proposal, I don't always return an owned value, a smart-pointer, or a reference (for each of those three, ergonomics would be nice). Instead I return an unhandy "thing", which requires .borrow() or .into_owned() to be used.

---

@8573

I don't think you should call it a "smart pointer", though. […] ^[2]

One reason why call it smart pointer can be found here:

@jbe

This trait is used, for example, by mmtkvdb::Txn::get:

fn get<'kr, K, V, C, KRef>(
    &self,
    db: &Db<K, V, C>,
    key: KRef
) -> Result<Option<V::AlignedRef<'_>>, Error> where
    K: ?Sized + Storable + 'kr,
    V: ?Sized + Storable,
    C: Constraint,
    KRef: StorableRef<'kr, K>, 

This looks horribly complex, but lets focus just on the (successful) return type Option<V::AlignedRef<'_>>. We basically return a pointer-like type to the stored value.

If we retrieve a string, then .get simply returns an ordinary reference to memory-mapped data on disk. But for some types like integers, we cannot do it becasue the memory-mapped data on disk will not have proper memory alignment (LMDB doesn't guarantee proper alignment). Here we must create a re-aligned copy of the data on disk. Freeing that memory should happen once the reference is no longer needed. This calls for a SMART POINTER!

And this smart pointer is exactly what Owned is. It is a wrapper which serves as a smart pointer to the wrapped value:

---

@CAD97

Either you call borrow early on and use the borrowed version, or you could (internally only) use a

struct LetMeDerefBorrowPlz<T>(T);
impl<T: Borrow<U>, U> Deref for T {
    type Target = U;
    fn deref(&self) -> &U { self.borrrow() }
}

(EDIT: I didn't test this. Looking at it a bit later: this won't tyck as is (uncovered U). )

However, I do agree that it would be nice to have some sort of MethodDispatchAs<T> trait which covers all types which have method dispatch to T via auto(de)ref, in addition to just Deref, which excludes T itself.

Hmmmm, where would such a bound be used? For the GAT, e.g. return type of mmtkvdb::Txn::get? Not sure if I fully understand it or whether it's also a bit ugly.

Meta: I feel like we're discussing now more about how Rust could be extended rather than helping me with a particular problem. (edit: or is MethodDispatchAs<T> something that can be implemented in today's Rust?) Thus I felt like IRLO was not a bad place to talk about these issues. I'm interested in how Rust could be improved to make these things better, not just how I can write a crate with today's Rust. Of course, I'm also not experienced enough yet to understand everything, so when writing on IRLO this also helps me understand things better, i.e. it's some sort of "support" I get. Anyway, I feel like both URLO and IRLO are not quite fitting for my purpose. On IRLO I feel like a "dumb user" who just doesn't understand the language, and on URLO I feel like questioning the language concepts itself instead of using the language (as it is). What does the pinned post on IRLO say?

Here is the hub for discussing everything related to the implementation and design of the Rust programming language .

This is not a support forum. Questions or requests for support using Rust should be directed to the user forum. This forum is for people contributing to the Rust compiler and standard toolchain, or otherwise working on changes to the language and its implementation.

Did my post on IRLO help me to get support? It wasn't my main intention, but it did help me to get support also. So the latter would be a reason to not post there. Did I want to discuss the implemenation and design of the Rust programming language? Yes, that would be a reason to post there. Am I contributing to the Rust compiler, standard toolchain, or am I otherwise working on changes to the language and its implementation? Not really, though I do occasionally write bug reports and you could see my posts as contribution. Perhaps the quality isn't well enough to make me eligible to post them on IRLO? Either way, I felt like my input wasn't really appreciated by most people (with some exceptions of course). I didn't feel fully comfortable.

Perhaps it would have been easier if there was just one forum instead of two. Also shifting this discussion from IRLO to URLO has been technically tedious. Perhaps I should just go to URLO next time even if I want to discuss language features and never post on IRLO unless I'm 100% sure about a topic?

Anyway, now we're here on URLO, and I think we can stay here. Unless someone tells me to go to IRLO with this!!!!1!!

---

@CAD97

Using impl IntoOwned as a return type (e.g. trait Parse) though seems odd. Unless generic users of Parse need to .into_owned(), the return type only needs to be bound on Borrow. All parser combinators I can think of are happy to deal exclusively in &[_], and e.g. trying to return Strings from a list combinator is actively a bad thing. The concrete instantiation knows if the given type is e.g. String or &str.

I wonder if what what you really want is a self-referential kind of thing, e.g. to yoke a borrowed output to an owned input.

Obviously with just a trait definition and not a set of expected uses it's not really possible to suggest an alternative; you could be relying on arbitrary details.

Let me try to find a good explanation for why I resort to use an IntoOwned bound on my GAT (generic associated type) AlignedRef that mmtkvdb::Txn::get returns:

The GAT determines at compile-time whether I return a borrowed or an owned value (or maybe both, depending on actual memory addresses encountered, though I didn't implement optional realignment, and it might come with more overhead than it saves). Thus the return type would either be &'a B, Owned<O>, or Cow<'a, B>. That's what the IntoOwned bound is about:

@jbe

IntoOwned is not a generic conversion from a type into an owned type. IntoOwned should be more understood as RefIntoOwned or RefWhichManagesOwnershipIntoOwned. These reference-like types are:

• &'a T (always borrowed)
• Cow<'a, T> (sometimes borrowed, sometimes owned, determined at run-time)
• Owned<T> (always owned)

There's still the curious case of OwnedRef, and I have the feeling that this might bring some things to surface that aren't well thought out yet.

Anyway, the generic AlignedRef<'a>: Deref<Target = B> + IntoOwned is an generalization of all of:

• &'a B (always borrowed)
• Cow<'a, B> (sometimes borrowed, sometimes owned)
• Owned<O> (always owned)

(Edit: Note that all three types are reference-like types, even Owned despite its name. Owned<O> isn't the "owned" type, but O is.)

Does that make sense? I need Deref to go to B where needed (and to have deref ergonomics, otherwise I could use Borrow), and I need IntoOwned to go to O without doing an extra (useless) clone.

I will look into what that "yoke" is. Maybe it's something I could need.

---

1. Providing fn(&self) -> &T with the guarantee that &Self and &T behave “the same.” ↩︎

2. I saw your "smart pointer" link, but I don't think that reference section supports your definition of "smart pointer".) ↩︎