You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While looking into adding this, I noticed that a few trivial functions of alloc::String are routed via FFI, e.g. cxxbridge1$string$len for String::len. So long as Vec has a guaranteed memory layout, and String is a Vec<u8>, then it should be possible to get the length out of rust::String::repr[1], and similarly for the pointer.
I bring this up because, if this would work reliably, then all these operators could be implemented with just an equality and a comparison function that operates on 2 string slices (technically two pointer + length pairs, since &str is not FFI safe), in addition to removing the accessors mentioned above.
alloc::String is not yet marked as repr_transparent, pending rust-lang/rust#70473.
Do you think having repr_transparent on String is really a requirement in practice for this case, or should this go ahead before the issue above is implemented ? Because personally, I can't see how the layout of String could differ from Vec<u8> in practice, given its implementation.
The C++ types should come with operators for
==
,!=
,<
,>
,<=
,>=
.The text was updated successfully, but these errors were encountered: