Skip to content

Allow tuples in untagged variants #6550

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 7, 2024
Merged

Allow tuples in untagged variants #6550

merged 1 commit into from
Jan 7, 2024

Conversation

tsnobip
Copy link
Member

@tsnobip tsnobip commented Jan 6, 2024

fixes #6544

@tsnobip tsnobip force-pushed the tuple-untagged-variants branch from 77fed8a to 2b8f4a5 Compare January 6, 2024 17:13
@tsnobip tsnobip requested review from zth and cristianoc January 6, 2024 17:36
Copy link
Collaborator

@zth zth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, we need to have code that checks the length of the array at runtime as well to see if it matches the tuple, right? So I think tuple needs to be its own code path fully.

I think here is where you'll want to change things to cover checking lengths when tuple is its own thing: https://github.com/rescript-lang/rescript-compiler/pull/6383/files#diff-41883149b99918ba2a405ce00ee26ec4679a3fdf02f1026fe98782983faa6c0a

Brain dump:

  • You'll need to track the length of each tuple, and make sure that there aren't multiple tuples with the same length, in addition to checking if there are arrays already
  • Next level: Support "array catch all" case by verifying that all tuples only have the same types as the array case

Edit: Or maybe it's fine to not check length at this stage when only one is allowed.

@tsnobip
Copy link
Member Author

tsnobip commented Jan 7, 2024

@zth I think it's already useful to have the possibility to have one case of tuple.

Being able to treat tuples a bit like we do for strings or ints is nice, but I think it's an addition that would belong in a followup PR. What do you think?

@zth
Copy link
Collaborator

zth commented Jan 7, 2024

@tsnobip I agree 👍 Extending should be a follow up.

This looks good to me, but I'd like @cristianoc have a final look as he knows his way around untagged variants better than me.

@cristianoc
Copy link
Collaborator

With only 1 case this looks good.
For future, Distinguishing sizes also opens the question on whether tuples of size Eg 2 can be differentiated based on their types.

@zth
Copy link
Collaborator

zth commented Jan 7, 2024

Ready to merge then? @tsnobip can you make a corresponding PR to the docs as well?

@tsnobip
Copy link
Member Author

tsnobip commented Jan 7, 2024

Sure I'll do the PR for the documentation!

@zth zth merged commit a10e02b into master Jan 7, 2024
@zth zth deleted the tuple-untagged-variants branch January 7, 2024 18:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow tuples in untagged variants
3 participants