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

Expand warning when expression result is ignored #1235

Merged
merged 3 commits into from
Jun 24, 2016

Conversation

taylorwood
Copy link
Contributor

@taylorwood taylorwood commented Jun 2, 2016

These changes attempt to address #1108. I ended up using a combination of the suggestions from the issue discussion, but am happy to change per feedback.

warning

@forki
Copy link
Contributor

forki commented Jun 2, 2016

This looks good. Could you please add a new test case under tests\fsharpqa\Source\Warnings that contains your sample from the screenshot? Thanks

@isaacabraham
Copy link
Contributor

Great stuff! 2 questions: -

  1. Why "expr" rather than "expression?
  2. I'm putting myself in the shoes of a C# or Python dev who has never seen this before - is the message clear as to why it's happening i.e. this is an expression, it has a result that is being ignored and F# warns you about this because it's trying to guide you towards writing pure functions etc. etc.?

@forki
Copy link
Contributor

forki commented Jun 2, 2016

I think "Use the ignore function" is what we would want to put into the "consider" part ("Consider to use the ignore function...").
Before that part we should give a short explanation why implicit ignore might be unwanted.

@isaacabraham
Copy link
Contributor

@forki yeah, exactly - there should be some description of why "throwing away" a result is considered "bad form" in F# and why this is potentially a code smell.

This will probably lead to a longer warning message than @KevinRansom would like though :-)

@taylorwood
Copy link
Contributor Author

@forki @isaacabraham I'm having trouble coming up with an explanation that isn't made redundant by the "consider" suggestions. Also, there are interop scenarios where ignore isn't bad form (collection mutators that return an item), but explaining pure functions and side effects succinctly is hard! I swapped the order to suggest binding first, since that's the more common F# idiom.

This expression has a value of type 'int' that is implicitly discarded. You probably mean to use the value or discard it explicitly. Consider binding to a name, e.g. 'let result = expression', or using the 'ignore' function, e.g. 'expression |> ignore'.

You probably mean to use the value, or explicitly discard it if you're evaluating the expression only for its side effects.

@forki
Copy link
Contributor

forki commented Jun 2, 2016

No we don't think ignore is bad.
We think implicit ignore is bad.

@taylorwood
Copy link
Contributor Author

@forki agreed. If we can settle on some reasonable message, I'll push another commit.

@KevinRansom
Copy link
Member

Lol bikeshedding.

I think this probably works okay:

The result of this expression is implicitly ignored. Consider using ignore to discard this value explicitly, e.g. 'expr' |> ignore', or 'let' to bind the result to a name., e.g. 'let result = expr'.

@taylorwood
Copy link
Contributor Author

Updated message from @KevinRansom's suggestion and added test re: @forki

@KevinRansom
Copy link
Member

@taylorwood, Hi mate, did you push your latest updates to the messages?

Thanks
Kevin

@taylorwood
Copy link
Contributor Author

@KevinRansom yes, I used your suggestion for the message in the last commit

@cartermp
Copy link
Contributor

This LGTM.

@KevinRansom
Copy link
Member

@taylorwood This looks great,

Thanks for taking care of this.

Kevin

@KevinRansom KevinRansom merged commit 760a50b into dotnet:master Jun 24, 2016
@cartermp
Copy link
Contributor

👍

@taylorwood taylorwood deleted the result-ignored branch June 24, 2016 18:57
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.

6 participants