Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom derive of IntoOwnedInner (or better solution) #9

Open
ZoopOTheGoop opened this issue Feb 6, 2024 · 3 comments
Open

Custom derive of IntoOwnedInner (or better solution) #9

ZoopOTheGoop opened this issue Feb 6, 2024 · 3 comments

Comments

@ZoopOTheGoop
Copy link
Owner

ZoopOTheGoop commented Feb 6, 2024

It's really annoying owning these types that are Cow all the way down, need to reduce verbosity, in principle this should be custom derivable for compound types. We also may want to reduce incidence of newtypes done with snapd_str_newtype and restrict them solely to types are used for input, or that we want to implement a convenience method on, and just use raw Cow for everything else.

@ZoopOTheGoop
Copy link
Owner Author

ZoopOTheGoop commented Feb 6, 2024

Okay, thinking about it more, instead of what we're doing, the newtypes should just hold Strings (etc) and requests should hold &references to them, and responses should hold Cow<'a, newtype>.

The drawback is that this means requests can't be cloned or stored in any way, which one may want to do if they send a particular request frequently :/

I guess we could try Borrow<String>?

E: Actually, this won't quite work :/
The general idea that Requests should exclusively deal in references (or Copy) types, and responses should deal in Cow is sound, but it's not clear how to actually deal with this. Perhaps the newtypes should simply be a convenience thing for the public API.

@ZoopOTheGoop
Copy link
Owner Author

After playing in the Playground, Cow is the only real way to do this, looks like we have to stick with the original plan.

@ZoopOTheGoop
Copy link
Owner Author

Well, one thing is for sure: we can reduce a lot of lifetime noise by using 'static for Owned types. I had psyched myself out of using them but I ended up remembering the quirks of lifetime subtyping that make types silently downgrade even if you "promise" 'static

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant