Skip to content
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

chore!: rename "Tuple<T0, T1, T2...>" -> "(T0, T1, T2...)" (schema::Declaration) #234

Merged
merged 1 commit into from
Sep 26, 2023

Conversation

dj8yfo
Copy link
Collaborator

@dj8yfo dj8yfo commented Sep 26, 2023

part of #231 resolution

@dj8yfo dj8yfo marked this pull request as ready for review September 26, 2023 13:24
@dj8yfo dj8yfo requested a review from frol as a code owner September 26, 2023 13:24
Comment on lines +654 to +674
if params.len() == 1 {
format!(r#"({},)"#, params[0])
} else {
format!(r#"({})"#, params.join(", "))
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we really need it? I mean, in Rust and Python tuples require to have this comma to disambiguate from just grouping expressions with parenthesis (2+2)*2, but I don't see a reason to have it here. Do I miss something?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This comma looks really jarring, and it may cause one to reconsider using the type of first element directly instead of one-element tuple).
Having it exactly the same as in rust has a benefit of possibility to parse it with syn, though parsing shouldn't be needed at all, as the same info is available via schema::Definition.


the change was primarily to help visually distinguish declarations of tuples from what would be derived for a generic struct named Tuple<T0, T1,...>

Copy link
Collaborator

@frol frol left a comment

Choose a reason for hiding this comment

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

Besides the comment I left above, I don't have any other concerns (it is also a breaking change, and might affect users, but I guess if we like this syntax more, it is better to break it with 1.0 release)

@dj8yfo dj8yfo merged commit 63cf36d into master Sep 26, 2023
7 checks passed
@dj8yfo dj8yfo deleted the rename_declarations_tuples branch September 26, 2023 19:15
@frol frol mentioned this pull request Sep 26, 2023
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.

2 participants