On: Rust Language Cheat Sheet

[pitaj]

If you use String which is heap allocated, you don't really need to worry about lifetimes.

&str on the other hand

[KingOfCoders → pitaj]

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 → KingOfCoders]

You 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 → phaylon]

Thanks, I will try that - fearing my code is littered with Arc ;-) - but sarcasm aside, thanks.

[phaylon → KingOfCoders]

I usually just have a `type Text = std::sync::Arc<str>` at the root, specifically during prototyping :)

[rmdashrfstar → phaylon]

How does this differ from just sharing &str?

[phaylon → rmdashrfstar]

A `&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 → phaylon]

I suppose my question is what motivates the use of atomically referencing counting string slice rather than borrowing?

[phaylon → rmdashrfstar]

You 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.