Muxed address support sketch for Soroban SDK, transfer_muxed edition#1447
Muxed address support sketch for Soroban SDK, transfer_muxed edition#1447dmkozh wants to merge 1 commit intostellar:mainfrom
transfer_muxed edition#1447Conversation
This just uses a separate interface/contract function that accepts `MuxedAddress` and doesn't introduce any opt-ins/outs of exposing the muxed address type. This introduces the `MuxedAddress` type that maps to either `AddressObject` or `MuxedAddressObject`.
| ScSpecTypeDef::Address => quote! { soroban_sdk::Address }, | ||
| ScSpecTypeDef::AddressV2(supports_muxing) => { | ||
| if *supports_muxing { | ||
| quote! { soroban_sdk::MuxedAddress } | ||
| } else { | ||
| quote! { soroban_sdk::Address } | ||
| } |
There was a problem hiding this comment.
What's the benefit of AddressV2 which is configurable, vs introducing a MuxedAddress that maps directly to the MuxedAddress in the SDK?
There was a problem hiding this comment.
Yeah, it could be MuxedAddress, with a caveat that it would be the only spec type that's seamlessly compatible with another spec type (Address). The option here tries to convey that both are semantically the same type, but with some additional options available. Both options are a bit weird; probably support for the variant types in the spec would be more clear than either one. But for a one-off exception I think both options are ok-ish (not pretty, but ultimately not too hard to deal with when parsing the spec).
There was a problem hiding this comment.
it would be the only spec type that's seamlessly compatible with another spec type
The spec types already have some oddities that cause them to overlap with other spec types. For example, The Option<> spec type overlaps with Void and every other value.
|
I think this was superseded by: |
2 participants
This just uses a separate interface/contract function that accepts
MuxedAddressand doesn't introduce any opt-ins/outs of exposing the muxed address type.