3 ms·

Generally external APIs which return pointers will be only to get views into the internal data. And you can return an `&mut` pointer if you want others to be ab

Generally external APIs which return pointers will be only to get views into the internal data. And you can return an `&mut` pointer if you want others to be able to mutate it, if possible (as in, if the borrow checker accepts it). If not possible, then you don't want to do that anyway, unless you redesign the internals. Generally to add mutation you might add another method in the situation you describe, but I can't think of such a situation coming up in a well-designed Rust API. (You're treating the API as if it would be designed the C++ way -- it wouldn't) FWIW most libraries do use a COW type in many places to get this flexibility. But in most situations you can just return mutable or immutable slices.

Matthias247 12y ago
My comment was not directly about having the ability to mutate or not. It's about that this API design causes close coupling between the API and the internal representation of the API. If you change your internal software structure and the data is stored in another way or you choose the make your library concurrent internally where different parts could mutate the vector while the user might request the same data in parallel then returning the slice would no longer be possible. And so you would have to change your external API and all consumers of the API only because you wanted to change internal things. But as I said: Depends on the use-case.
- Manishearth 12y ago
  > If you change your internal software structure and the data is stored in another way or you choose the make your library concurrent internally where different parts could mutate the vector while the user might request the same data in parallel then returning the slice would no longer be possible In that case you wouldn't want to return a slice, because it would be dangerous. The compiler would prevent you from invalidating an API use case. I don't see a problem here.

Matthias247 12y ago

My comment was not directly about having the ability to mutate or not. It's about that this API design causes close coupling between the API and the internal representation of the API. If you change your internal software structure and the data is stored in another way or you choose the make your library concurrent internally where different parts could mutate the vector while the user might request the same data in parallel then returning the slice would no longer be possible. And so you would have to change your external API and all consumers of the API only because you wanted to change internal things. But as I said: Depends on the use-case.

Manishearth 12y ago
> If you change your internal software structure and the data is stored in another way or you choose the make your library concurrent internally where different parts could mutate the vector while the user might request the same data in parallel then returning the slice would no longer be possible In that case you wouldn't want to return a slice, because it would be dangerous. The compiler would prevent you from invalidating an API use case. I don't see a problem here.