4 ms·

I would assume it would be bad API design in Rust too. For all use-cases that are possible this kind of API it would be safe to use a const reference to a vect

I would assume it would be bad API design in Rust too. For all use-cases that are possible this kind of API it would be safe to use a const reference to a vector it C++ too. Of course with the difference that in Rust the correct use can be statically verified. But I think for a really flexible API that allows parallel modification you should go for a copy or some kind of immutable-vector oder copy-on-writer-vector type in both languages.

Manishearth 12y ago
Why would it be bad API design in Rust? Rust ensures that it's safe. (Besides, all these were internal functions that wouldn't be used as an API) You don't always want parallel modification.
- Matthias247 12y ago
  Yes - it guarantees that it's safe at the moment. But it limits how the API (especially on provider site) can be used in the future. If there comes up a need that that the data might need to be mutated at one point in future you might need to change it to an other interface in both of the languages and then change probably lot's of consumers according to it. If it's only an internal API that might be ok - for a public API it would be to inflexible for my taste.
  - Manishearth 12y ago
    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.

Manishearth 12y ago

Why would it be bad API design in Rust? Rust ensures that it's safe. (Besides, all these were internal functions that wouldn't be used as an API) You don't always want parallel modification.

Matthias247 12y ago
Yes - it guarantees that it's safe at the moment. But it limits how the API (especially on provider site) can be used in the future. If there comes up a need that that the data might need to be mutated at one point in future you might need to change it to an other interface in both of the languages and then change probably lot's of consumers according to it. If it's only an internal API that might be ok - for a public API it would be to inflexible for my taste.
- Manishearth 12y ago
  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.