feature: Should the arri specification support Tuples? #163
Comments
|
As an alternative maybe we add support for Fixed-Size arrays instead? That could cover some of the cases where Tuples are useful, but would be easier to implement across different languages (*cough* *cough* go) |
I believe both would be the more ideal option, and just using a fallback on the client size. (Eg a fixed size array on the client when no tuple support is present, and if no fixed size arrays exist just fallback to a regular array) |
|
Yeah I guess the issue is that a fixed size array only works as a fallback when all the tuple subtypes are the same like this: typedef MyTuple = (int, int);Once we add multiple types falling back to a fixed size array doesn't work anymore: // go literally has no way of representing this other than [3]any
typedef MyTuple = (int, bool, string);My main concern adding tuples could create inconsistent experiences across different langs. |
|
Ideally if we could get tuples to work that would be great. But I also don't want it to create this dynamic where devs have to keep track of which features work properly in which languages. Making things behave consistently is pretty important imho. |
Ahh true, totally forgot about this.
Since we are statically creating code anyway, can't we create an object that matches the used tuple struct? So that something like this gets generated: type MyTuple struct {
T0 int
T1 bool
T2 string
}from typedef MyTuple = (int, bool, string);That should be supported in all languages right? About the fixed size arrays, might be useful to have this as a type option as well, in the languages that don't support it can use a array implementation; but for the ones that do this might be a performance impr 8000 ovement. |
That's true. Using this approach we should be able to support this in any of the target clients. Tuple support would still be limited in the go server implementation, but at least any go clients would be supported easily. Also for the go server I prolly can make type helpers for tuples with 2 and 3 values which would be the most common tuple uses anyway.
Yeah agreed. Maybe I'll add support for fixed size arrays first since that's more straightforward and then look to add true tuple support down the line. |
Describe the feature
This feature would allow Arri servers and clients to send Tuple types over the wire. For JSON payloads, Tuples can be encoded as JSON arrays.
Supporting this feature would require adding a new
tupleform to Arri Type Definition. Perhaps it could look something like this:{ "tuple": [ { "type": "string" }, { "type": "boolean" }, ] }Additional context
Potential Downsides
Some popular languages do not have native Tuple support such as
JavaandGo. Meaning if we accept this that we potentially make it difficult to integrate those languages into the ecosystem. Of course Arri could create it's own Tuple implementation when targeting those languages but it's still something to consider.There's also the case that while Typescript can define tuples like so
type MyTuple = [number, number]. You don't actually get runtime safety for this, since it's still a JavaScript array under the hood. But I guess that's the case for most Typescript things 🤷Would you be willing to implement this feature?
Yes
The text was updated successfully, but these errors were encountered: