Skip to content
This repository has been archived by the owner on Oct 25, 2024. It is now read-only.

Tuple support #1476

Open
Tracked by #1470
Braqzen opened this issue Nov 22, 2023 · 1 comment
Open
Tracked by #1470

Tuple support #1476

Braqzen opened this issue Nov 22, 2023 · 1 comment
Assignees
Labels
documentation Improvements or additions to documentation sway

Comments

@Braqzen
Copy link
Contributor

Braqzen commented Nov 22, 2023

When attempting to capture tuples there was an issue.
I was informed that in order to capture a tuple it must be wrapped in a struct and its components to be individually accessed.

If that information is correct then native type support should be implemented (ref: #1475) otherwise if it is incorrect then documentation of tuple support ought to be added.

@ra0x3
Copy link
Contributor

ra0x3 commented Nov 29, 2023

@Braqzen

  • This is a bit similar to my comment in Wrapping all types in structs #1475

  • While unlike log(5), I believelog((5, 6)) produces a LogData receipt (complex type), however, we don't decode that log((5, 6)) because there's nothing to identify that tuple with

    • We need something to identify the data that we're gonna decode, else you wouldn't be able to include the unamed arg in your indexer handler
      • Named: fn do_a_thing(tuple: MyNamedTupleThing)
      • Not named: fn do_a_thing(tuple: (u64, u64))
  • What could we do?

    • We could adding decoding support these unnamed/raw tuples
  • What would this support look like?

    • We'd have to derive a new decoder field for each of these tuples (e.g., tuple_u64_u64_decoded)
  • Why can we probably not do that?

    • Complexity
      • We don't need to manually decode tuples (the SDK does it)
      • However, what would we call this tuple? (u64, (u32, u8), str[5], bool) ?
  • To be clear, adding support for these raw tuples isn't impossible, but I do think it's a little too complex for such a little benefit - especially when users can just struct TupleThing{ a: (u64, (u8, bool)) } with little to no additional work

    • If anything, including these raw types in containers actually makes things a bit easier to follow
  • I'll mark this as a documentation improvement, where we need to explicitly say some of things things and include examples

@ra0x3 ra0x3 added the documentation Improvements or additions to documentation label Nov 29, 2023
@ra0x3 ra0x3 self-assigned this Nov 29, 2023
@ra0x3 ra0x3 added the sway label Nov 29, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
documentation Improvements or additions to documentation sway
Projects
None yet
Development

No branches or pull requests

2 participants