6 ms·

A C++ function returning pointer to vector, or a public field of that type, would be considered bad API for the reasons mentioned in this article. The solution

A C++ function returning pointer to vector, or a public field of that type, would be considered bad API for the reasons mentioned in this article. The solution is to not do that. I'm not sure that Rust's ability to allow shared ownership of a vector makes this API pattern any better.

Rusky 12y ago
What's wrong with that API pattern if the compiler guarantees that it will be used correctly? It's certainly simpler and allows for better code reuse.
lobster_johnson 12y ago
But it's a bad pattern in other languages because they don't guarantee safe access. Rust does, thus making it a good pattern. It's like saying that driving your car off a cliff is always a bad idea even when you've acquired a car that can fly.
- thrownaway2424 12y ago
  It's a bad pattern in any language because it exposes too much details of storage layout and violates encapsulation. You probably don't want to expose internal implementation details in your API unless such exposure is critical to performance, and if it is critical to performance it seems unlikely that you'd be writing it in anything other than C++ anyway.
  - lobster_johnson 12y ago
    This seems orthogonal to internal implementation hiding, especially if the "API" is not a public library API, say, but an internal one. Then again, contracts about who can modify what data are also part of any public API; historically, there have been plenty of (quite decent) APIs that have returned pointers to internal structures that have limited lifetimes, in languages like C that don't enforce lifetimes at all.
Matthias247 12y ago
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.

Rusky 12y ago

What's wrong with that API pattern if the compiler guarantees that it will be used correctly? It's certainly simpler and allows for better code reuse.

lobster_johnson 12y ago

But it's a bad pattern in other languages because they don't guarantee safe access. Rust does, thus making it a good pattern. It's like saying that driving your car off a cliff is always a bad idea even when you've acquired a car that can fly.

thrownaway2424 12y ago
It's a bad pattern in any language because it exposes too much details of storage layout and violates encapsulation. You probably don't want to expose internal implementation details in your API unless such exposure is critical to performance, and if it is critical to performance it seems unlikely that you'd be writing it in anything other than C++ anyway.
- lobster_johnson 12y ago
  This seems orthogonal to internal implementation hiding, especially if the "API" is not a public library API, say, but an internal one. Then again, contracts about who can modify what data are also part of any public API; historically, there have been plenty of (quite decent) APIs that have returned pointers to internal structures that have limited lifetimes, in languages like C that don't enforce lifetimes at all.

Matthias247 12y ago

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.