Repository navigation
Conversation
Signed-off-by: Ikeh Chukwuka <mrikehchukwuka@gmail.com>
Signed-off-by: Ikeh Chukwuka <mrikehchukwuka@gmail.com>
…ex<I>` tag type Signed-off-by: Ikeh Chukwuka <mrikehchukwuka@gmail.com>
to_array and get
thunderseethe
left a comment
There was a problem hiding this comment.
This is a great start! Thanks for the submission.
after studying forward_list and the use of &mut for c++ move, i was curious to ask if there have been any discussion about offering rust style move (by value)? i understand this would be a mismatch between both languages, but i'm curious for case when the moved-from c++ object itself needs not to be used after it is moved. because i initially implemented move to take ownership of the other object.
I think this is definitely one of the more interesting questions about FFI between C++ and Rust. I would love to hear how you would tackle some of the problems for array. Especially around how to move items in and out of the array in both languages. Where Rust expects to be able to destructively move things out of an array that it owns, callers have to be careful not to leave an array element in an invalid state where Rust expects it won't be referenced again but C++ attemps to read it expecting the element to be left in a moved-from state.
I left one minor comment on section 1, but overall looks good. Can you show me an example of some failing overloads for array (per section 2)?
| /// C++ also has a `const T&& get(const std::array&&)` overload but Rust types can't be `const`, | ||
| /// so a constant rvalue array has the same Rust type as a moved array. That overload | ||
| /// can't be represented separately from this one. | ||
| fn get(array: StdArray3, _index: Index<0>) -> T { |
There was a problem hiding this comment.
For methods that take an array "by value" like this, how can we uphold the lifetime guarentees here? This won't really matter for this case where T is an int but what if T was an object with a destructor. How can we ensure that when we return T by value that T won't get dropped when we drop the array initially holding it. If we can't, can we document the invariants required of our array when we call this method?
this pr adds rust wrappers for
std::array<int, 3>overloads covering three method names, the constructors,to_arrayandget.std::arrayconstructors are aggregate initialization with 0 toNinitializers, in addition with the copy and move constructors. all of them are implemented forN = 3, so the constructor set is complete. unlikeforward_list, none of its overloads clash becausestd::arrayhas nocountorvalueconstructors.c++ has two zero-argument forms (
a;anda{};), but only one of them can be a rust overload, so i used value-initialization.the constructors are the
std::arrayoverloads that differ by more thanconstor&/&&, so i chose to use two non-member functions as examples to show that rule:to_arrayoverloads on&and&mutbuilt-in arrays, matching the c++ lvalue and rvalue versions.gettakes the element index as a template argument, and because the macro doesn't support const generics, each index gets its own overload through anIndex<I>tag type. all three indices were done for&, but only index 0 was done for&mutand by-value, since every other index works the same way. but for theconst&&overload it can't be represented, because rust types can't beconst.i implemented
getto use&'staticlikeforward_list::front, and its test leaks the arrays the same way theforward_listtest does.i skipped the other
std::arrayoverloads, with theScopesection in the module doc listing each one with the reason.ai use: i used claude (web) to get explanation across different parts of the codebase, especially the
overload!implementation and understanding of how overloads dispatch.the code implementation are mine, written after studying
forward_listimplementation, andstd::arrayspecs from c++.after studying
forward_listand the use of&mutfor c++ move, i was curious to ask if there have been any discussion about offering rust style move (by value)? i understand this would be a mismatch between both languages, but i'm curious for case when the moved-from c++ object itself needs not to be used after it is moved. because i initially implemented move to take ownership of theotherobject.closes #34
Limitationsdoc sectionErgonomicsdoc sectionIncompatibilitiesdoc sectionWorkaroundsdoc sectionInexpressible Overloadsdoc section