rs-stellar-xdr truncated assignment for string/vec

[warm shell]

rs-stellar-xdr is strict about vec and string types. It won't let a value be assigned to a string or vec field without a conversion (which is cheap because it is not a copy) where the conversion checks the size.

This is why when assigning to a string field we have to do "my string".try_into()?.

I've got some cases where I want to assign and truncate to whatever the limit is so that the assignment is infallible.

I'm not sure how to introduce that to the rs-stellar-xdr API of the StringM and VecM types.

[lapis jay]

try_into iterates through a bunch of options though so wouldn't it be cheaper to use the specific one?

[warm shell]

One way to introduce it is to implement the infallible Into<> / From<> traits, but that doesn't feel right, because it would be an incomplete conversion, and it could be used by people who think it is guaranteed to convert the entire value.

[warm shell]

try_into for StringM and VecM just check the length and then moves the value if it can, depending on the types involved. For example: https://github.com/stellar/xdrgen/blob/57beb46bd3d1c77529218430bd6ed87cd69ac394/lib/xdrgen/generators/rust/src/types.rs#L1683-L1694

[lapis jay]

i haven't had that problem yet because i was converting my strings into bytes then back again lol

[lapis jay]

ah i think i am thinknig of a different try_into() sorry about that

yes i thought you meant rs-soroban-sdk

for one

:_

is it the same thing?

[warm shell]

I think the best thing I can do to add it is add a function like from_truncated to StringM and VecM. The function would be infallible, and truncate the input to whatever size fits into the destination.

[lapis jay]

gotta look at the code sorry for my useless blabbering... i think i confused myself

[warm shell]

Nah not the same thing.

[warm shell]

@spice basin Does that seem reasonable to you?

[fossil zealot]

I agree. Into/From docs do say "A value-to-value conversion that consumes the input value.", and a truncated version is not 1:1. I guess being explicit is better with the proposed "from_truncated"? Hmm... I wonder if it make any sense to make this a trait?