I'm getting the impression from the compiler that if I want a struct with a path in it, I should really use a PathBuf - you can't use Path, it's !Sized - using &Path means you now need lifetimes everywhere - why does Path::new return &Path?
-
Show this thread
-
like where is the Path actually stored? who owns it?
2 replies 0 retweets 1 likeShow this thread -
Replying to @mountain_ghosts
not sure if the docs ever say it but: Path is to PathBuf like str is to String
2 replies 0 retweets 1 like -
Replying to @killercup
it does but I'm equally unsure about when one should put a String vs a &str in a struct field
2 replies 0 retweets 1 like -
Replying to @mountain_ghosts @killercup
The latter, basically only when it's 'static or you're comfortable threading lifetimes "I need to describe some existing text, and I make no sense without it" is &str, "I need to hold some text" is String
2 replies 0 retweets 3 likes -
Replying to @myrrlyn @mountain_ghosts
yeah, it's one of the tough choices rust requires you to make. so `str`/`Path` is always a view into a slice of memory that lives somewhere and is owned by something (not you). using the owned versions is way easier at the cost of copying memory around
3 replies 0 retweets 3 likes
There's also the third option of `Cow<str>`, which requires the same lifetime threading as `&str`, but allows you to own the data if your caller doesn't want to have to own it, or potentially avoid copies (but you should probably just use String unless you have bms saying so)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.