Can the lifetime of &self and 'c teased apart in the signatures of some methods? about cookie-rs HOT 8 CLOSED

Hmm, after looking at it a bit, it seems that the Cookie struct uses Cow so it can either own the strings or have just references. If it owns the stuff, the lifetime of the returned strings naturally should not exceed the lifetime of Cookie, so it might or might not be tied to the lifetime of Cookie.

from cookie-rs.

Is there any widely-used enum in the ecosystem that is used to have two different lifetimes? A bit like Cow but for borrowing from it, so that there would be different lifetimes for a variant that has been borrowed from the string owned by Cow, and a variant that has been re-borrowed from a reference in Cow. That would sound the right thing to do in this situation, but I've never encountered such an enum. Should we open a thread to some community forum to discuss borrowing from Cow more widely?

from cookie-rs.

I made some some experiments here with such an enum. (Called it VarLifetimes) https://github.com/golddranks/cookie-rs/tree/experiments It seems like it'd deserve its own crate though. Are you aware of any already existing similar things? This kind of a thing might be valuable with libraries that want to support optionally zero copy parsing things.

from cookie-rs.

Yeah I think the only recourse here would be to expose the underlying storage. There'd need to be a method that returns both variants, and at runtime you'd assert that the 'c lifetime was the one returned, not the &self lifetime.

from cookie-rs.

In my experiment I made it return an enum that contained a short (&'s self) and a long (&'c) lifetime. Both are always coercible to the shorter one, so a helper method .short() returning a ref with the short lifetime isn't too bad ergonomics-wise. Using that one can always use the returned ref as it currently is, i.e. with the lifetime of a self ref to Cookie. I also implemented Deref which allows calling methods on the ref like one would currently call on the returned ref.

However, the ergonomic sugar ends there – I tried to implement the Eq traits too to make the tests pass without adding any explicit calls to the .short() method, but it seems that Option<T> and types like that are hard. The PartialEq impls on them are implemented only for the same inner type, and I'm unable to implement PartialEq between Option<&T> and VarLifetimes<'short, 'long, T> because of coherence issues.

That means that assert_eq!(Some("www.rust-lang.org"), cookie.domain()) isn't possible without calling the helper method: assert_eq!(Some("www.rust-lang.org"), cookie.domain().map(|d| d.short()))

Then again, I'm not sure how "transparent" a double-lifetime wrapper type like VarLifetimes should be, if it or something like it would be actually used.

from cookie-rs.

Another, possibly better possibility is to have simply a another set of methods on Cookie that return Option<&'long str>.

from cookie-rs.

Yeah so that actually sounds like the best option, Option-based accessors that maybe return a "long" string where otherwise the infallible operation with a "short" lifetime is always available too

from cookie-rs.

Closed by 74b9002.

from cookie-rs.