-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Refactor lexer functions #4288
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
Refactor lexer functions #4288
Conversation
@bonjune could you please review this PR? |
I'll look into it today. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like how the pattern matching here improves readability.
But, as I left a comment, if expression should be preferred for boolean values.
@bonjune |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good!
Have a good day. Thank you.
@bonjune |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
P.S.
https://doc.rust-lang.org/std/primitive.bool.html#method.then_some
I read bool's two method implementation: bool::then
and bool::then_some
, whose behaviors are subtly different. The key thing is here: the former lazily evaluated the passed closure while the latter one evaluates passed value eagerly. In this case, bool::then
is a proper choice because we don't to evaluate the function only when take_char
is true. (And you made the right decision, I think)
cc @youknowone
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
I refactored following lexer functions.
lex_number
take_number
at_exponent
is_identifier_continuation
What I have done are as follows.