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

Always require semicolon or newline before method body #11854

Draft
wants to merge 16 commits into
base: master
Choose a base branch
from

Conversation

FnControlOption
Copy link
Contributor

@straight-shoota
Copy link
Member

I believe the same problem applies to many more uses of skip_token_end. So it's probably better to look at other uses as well. And extract the common behaviour to a dedicated method (consume_token_end maybe).

Copy link
Member

@straight-shoota straight-shoota left a comment

Choose a reason for hiding this comment

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

Thanks for the enhancements and the very clear commit history 🙇

src/compiler/crystal/syntax/parser.cr Outdated Show resolved Hide resolved
@straight-shoota
Copy link
Member

Thanks for the many recent additions. I understand you have incorporated an implementation of the changes discussed in #11209?

To me that feels a bit much for this PR, though. Statement end before method body should be considered a separate feature from what comes after the name of a type def.

If you don't mind, I can take care of extracting this concern to a different PR.

@FnControlOption
Copy link
Contributor Author

Opened #13375

As for this PR, I think I need to go back to the drawing board. def f(x) puts x end is both valid Ruby and Crystal, and requiring a semicolon in this case seems unnecessarily restrictive. I think a semicolon/newline should only be required if the method header (a) has both no parameters and no parentheses; or (b) has anything after the parentheses (i.e. an explicit return type and/or any generic type parameters).

@straight-shoota
Copy link
Member

I created #13386 to discuss the intended behaviour.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants