5 ms·
If you use String which is heap allocated, you don't really need to worry about lifetimes. &str on the other hand
by pitaj 6y ago
If you use String which is heap allocated, you don't really need to worry about lifetimes.
&str on the other hand
- KingOfCoders 6y agoYes, String was an oversimplification, String means I either own or copy it, both things I usually don't want to do, so I end up - as you've said - with &str.
- phaylon 6y agoYou might want to look into using `Arc<str>`. It's an immutable string slice that can have many owners and will be dropped once the last one is done with it.
- KingOfCoders 6y agoThanks, I will try that - fearing my code is littered with Arc ;-) - but sarcasm aside, thanks.
- phaylon 6y agoI usually just have a `type Text = std::sync::Arc<str>` at the root, specifically during prototyping :)
- rmdashrfstar 6y agoHow does this differ from just sharing &str?
- phaylon 6y agoA `&str` is a borrow of the string slice data, and has borrowing semantics. An `std::sync::Arc<str>` on the other hand isn't borrowed but has shared ownership and is atomically reference counted. Does that answer the question? Could you expand on what you mean by sharing `&str`?
- rmdashrfstar 6y agoI suppose my question is what motivates the use of atomically referencing counting string slice rather than borrowing?
- phaylon 6y agoYou can store it independently without it being borrowed. So your structs don't need lifetimes. I consider it a midpoint between `String` and `&str`. Most of the convenience of `String` (barring mutation) but less costly.