3 ms·
Yes, 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.
by KingOfCoders 6y ago
Yes, 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.