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 Ref/Cow to preserve &'static str
?
#4
Comments
I'm not sure I understand. |
Maybe you are talking about onboarding? If you use |
KStringCow and KStringRef are roughly
This let's me have functions that return references that I can turn back into owned types without losing track of the |
Might need to see an example sometime. For some reason I'm just not getting it. If you borrow, you'd need to have a copy of the owned item or else the borrow wouldn't borrow. If you have a static...well, you have a static. Are you talking something like my conditional ownership feature? (a side effect of using |
In liquid, some data is dynamically generated and some comes from a previous allocation. I could still use a |
Ok, if you can point me to a worked example or spot in the source that illustrates this. I'm not sure I 100% follow the use case (because in my mind, FlexStr is the antithesis of |
In "liquid", you can directly access the elements of an Array or the members of an Object. There are also some implicit fields, See https://github.com/cobalt-org/liquid-rust/blob/master/crates/core/src/model/find.rs#L161 |
but like I said, a |
For more context on liquid, see https://shopify.github.io/liquid/ |
I was thinking the other way around (passing in, not returning). I can definitely see use cases where you want to return a 'view' into something but don't necessarily want to copy it... or maybe you have conditional ownership (like what you are doing it seems). Early on I played with ideas like having a 3rd and 4th type for this (I called it I'll do more thinking on what makes sense, but not against bringing that idea back. |
I would assume a new Rust user would generally not be using one of these crates :) However, a couple items down on my priority list is creating yet-another string type, one focused on ease of use and general performance. The idea is to have as few lifetimes in this API as possible, so each string function would return an owned type. See https://docs.rs/eztd/latest/eztd/struct.String.html and https://epage.github.io/blog/2021/09/learning-rust/ |
You kinda just described my goal with |
I figured out how to support borrowed strings. In hindsight it was obvious. Will be in next release. |
This was also one of they key early features for
KString
so thatliquid
could pass around data throughout the program and avoid allocations for this data.The text was updated successfully, but these errors were encountered: