When returning an immutable reference to a private struct field. (On mobile and used vertical bars instead of a bunch of HTML codes)
You may be better off with
&[String]as a read-only view ofVec. To get&[&str]I think you need to create a new collection to hold the&strvalues. (Stringand&strhave different memory representations.) But the choice depends on what you want to do - maybe providing&strvalues adds a convenience that is worth creating a second collection.For the Option case I would go with
Option<&[String]>. My understanding is thatOption<&T>is the same size as&Tfor anyTso an owned Option wrapper is zero-cost. If the reference pointer is null then Rust interprets that asNone. Besides you usually want ownership of anOptionso you canmapit or whatever else you want to do.Right, I want the convenience of &[&str] , but if it requires creating a second collection then I think &[String] is better. Use cases that require &str can just map to as_str.
Why not &[String]?
A vec and a string are basically the same thing (a series of bytes)
In the context of vectors I prefer my APIs to return an empty set rather than an None-option. This makes handling it much easier because you can still iterate over it, it just has nothing.
This might involve the compiler making an allocation of an empty array but most of them (gcc, ghc) will now what you are doing and optimize the null check on the empty array to a bool check.
In the context of vectors I prefer my APIs to return an empty set rather than an None-option. This makes handling it much easier because you can still iterate over it, it just has nothing.
I can see that argument. But you can also iterate over an Option-wrapped response with something like
for x in xs.into_iter().flatten() { ... }, and theOptiongives you an extra bit of information that can be helpful in certain cases.Vec::new is const and thus can’t allocate anyways.
