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
{{ message }}
This repository has been archived by the owner on Oct 25, 2024. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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
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.
The text was updated successfully, but these errors were encountered: