Skip to content

Add a compiler warning for lowercase literals in patterns#666

Closed
dungpa wants to merge 4 commits intodotnet:masterfrom
dungpa:literals
Closed

Add a compiler warning for lowercase literals in patterns#666
dungpa wants to merge 4 commits intodotnet:masterfrom
dungpa:literals

Conversation

@dungpa
Copy link
Copy Markdown
Contributor

@dungpa dungpa commented Oct 3, 2015

UserVoice request (approved for F# 4.x): http://fslang.uservoice.com/forums/245727-f-language/suggestions/6668206-warn-when-literal-attribute-is-used-with-lowercase

This is a small and low-risk change to warn users when lowercase literals are ignored in favor of variable binding patterns.

Unit tests have been added.

@neoeinstein
Copy link
Copy Markdown
Contributor

I like it, and it looks good from my review.

@dungpa
Copy link
Copy Markdown
Contributor Author

dungpa commented Oct 5, 2015

@neoeinstein Thanks for reviewing. It's really useful.

@vasily-kirichenko
Copy link
Copy Markdown
Contributor

Very important warning. Great job! 👍

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

when would name be empty?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure it will happen. The check is there to make sure that the index access (name.[0]) is totally safe.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Ok me neither. However it does seem surprising that a identifier is the empty string.

@dsyme
Copy link
Copy Markdown
Contributor

dsyme commented Oct 8, 2015

This looks good to me.

@KevinRansom
Copy link
Copy Markdown
Contributor

committed.

@KevinRansom KevinRansom closed this Oct 9, 2015
@dungpa dungpa deleted the literals branch October 9, 2015 07:22
@dungpa
Copy link
Copy Markdown
Contributor Author

dungpa commented Oct 9, 2015

@KevinRansom I think it's better to reference the PR number and the issue number (if there is one) in the commit message. As it is committed now, it's really hard to blame the original author for bugs in the original PR :-).

@KevinRansom
Copy link
Copy Markdown
Contributor

I screwed up the commit, I just reverted and am going to attribute it properly.
Sorry, it's kind a late here.

@PatrickMcDonald
Copy link
Copy Markdown
Contributor

A quick look at the PR # explains everything!

KevinRansom pushed a commit that referenced this pull request Oct 9, 2015
@KevinRansom
Copy link
Copy Markdown
Contributor

When I rebased, I forgot to set the author correctly. There are many times when I wished we just pressed the merge button.

Once again sorry for the brain-fart. Now it's time for bed.

Kevin

@forki
Copy link
Copy Markdown
Contributor

forki commented Oct 9, 2015

Dude, you are the one that is merging. Just make that decision to use the merge button. ;-)

@dungpa
Copy link
Copy Markdown
Contributor Author

dungpa commented Oct 9, 2015

@KevinRansom No worries. I don't mind at all. The main problem is traceability and maintainability that we have to be careful when merging PRs.

@vasily-kirichenko
Copy link
Copy Markdown
Contributor

@forki 👍

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.

9 participants