Hacker News Reader

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

&str on the other hand

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.

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.

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

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

How does this differ from just sharing &str?

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`?

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

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.

Reply on news.ycombinator.com