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

Improve error reporting: Warning when expression result is ignored #1108

Closed
Tracked by #1103
isaacabraham opened this issue Apr 24, 2016 · 7 comments
Closed
Tracked by #1103

Comments

@isaacabraham
Copy link
Contributor

isaacabraham commented Apr 24, 2016

What

The following code snippet returns a warning that could be improved:

let foo a b = a + b
let x =
    foo 5 10
    20

The warning generated is: -

warning FS0020: This expression should have type 'unit', but has type 'int'. Use 'ignore' to discard the result of the expression, or 'let' to bind the result to a name.

Why

A newcomer to F# will often not understand this; particularly if they come from a statement-focused language where the result of an expression can be arbitrarily discarded. Making this message clearer will not only reduce confusion but could also help new developers understand the value of expressions vs statements.

How

The warning could be improved as follows: -

The expression foo 5 10 returns an int which is currently being ignored. If you do not require this value, you should explicitly ignore it using the ignore function e.g. ignore (foo 5 10) or bind the result to a name e.g. let result = foo 5 10

@smoothdeveloper
Copy link
Contributor

Also, not directly related but worth mentioning, while introducing F# for unit testing, I've seen this:

[<Test>] let ``my test`` () =
  // some code

  ignore

which gives very interesting behaviour with NUnit.

if ignore could be treated specifically and having a warning when trying to return it when the function doesn't have return type specified, that would save some new comers to make that mistake.

@isaacabraham we somehow should try to make the formatting consistent (when error shows how to change the code, it should always be with same quoting style, etc.). I believe all messages are documented on MSDN so we will want something which doesn't change.

Actually, I think the actual detailed messages should be left to someone in charge of it with those concerns in mind and the community should mostly put efforts on implementing the technical part in the compiler.

@lulu-berlin
Copy link

Another wording: The return value of the expression 'foo 5 10' is implicitly ignored here. Use the 'ignore' function to discard this value explicitly, e.g. 'ignore (foo 5 10)', or bind it to a name to refer to it later in the code, e.g. 'let result = foo 5 10'

@dsyme
Copy link
Contributor

dsyme commented Apr 26, 2016

Just to mention that the compiler is not particularly well set up to quote the source text of expressions in error messages. So it would be normal to just red-squiggle the expression range instead, giving a text something like this

The value of this expression is implicitly ignored. Use the 'ignore' function to discard this value explicitly, e.g. 'foo 5 10 |> ignore', or bind it to a name to refer to it later, e.g. 'let result = foo 5 10'

@forki
Copy link
Contributor

forki commented Apr 26, 2016

Yes I already learned that part. Also such expressions can be really huge.
We should always try to find wording where the expression is not quoted. We
can probably still quote simple names of things.
On Apr 26, 2016 2:08 PM, "Don Syme" notifications@github.com wrote:

Just to mention that the compiler is not particularly well set up to quote
the source text of expressions in error messages. So it would be normal to
just red-squiggle the expression range instead, giving a text something
like this

The value of this expression is implicitly ignored. Use the 'ignore'
function to discard this value explicitly, e.g. 'foo 5 10 |> ignore', or
bind it to a name to refer to it later, e.g. 'let result = foo 5 10'


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1108 (comment)

@forki
Copy link
Contributor

forki commented May 12, 2016

so what is the best thing that doesn't quote the expression?

@lulu-berlin
Copy link

Well, I suppose that if you want to avoid quoting, you can just omit the "e.g." parts. If it's a matter of size, maybe an upper limit can be set.

@isaacabraham
Copy link
Contributor Author

Upper limit - good idea. Failing that, how about: -

This expression returns type int which is currently being ignored. If you do not require this value, you should explicitly discard it using the ignore function e.g. ignore (expression), or bind the result to a name e.g. let result = expression

I'm personally not a massive fan of this practice of abbreviating everything to just expr!

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

No branches or pull requests

5 participants