Improve Error Reporting: Make FS0039 easier to read at a glance.

[isaacabraham]

What

The following error message is super common and could be made less intimidating:

type Person = { Name : string }
let isaac = { Name = "Isaac" }
let fullName = isaac.Fooo + " Abraham" // The type 'Person' does not define the field, constructor or member 'Fooo'.

Why

The error message makes perfect sense, but for the beginner I feel it could be made more welcoming. In addition, the fact that it shows the type rather than the symbol name is a little confusing - especially if that type has been inferred.

How

I would prefer to see an error something like as follows:

• isaac.Fooo does not exist (isaac is type Person).
• Unknown member isaac.Fooo (isaac is type Person).

Notice that we use the same symbol name and path as the actual code sample, which hopefully draws people's attention to the source of the issue. In the current error message, you have to read all the way to the end to see what the issue is.

I suppose we could keep the current "type-oriented" message but still improve it e.g.:

• Fooo does not exist on the type Person.
• Fooo does not exist on this symbol, which has type Person.

I'm not sure when else this error message is shown, so it's possible I've missed some other obvious cases etc.

[jasiozet]

As a fresh neophyte, I think that the current error is mostly fine.
The first 3 proposition are fine too. The 4th one is worse IMO.

[edgarfgp]

I think we can take some inspiration from Elm here . I like the error message

[isaacabraham]

@edgarfgp we actually do that already, as long as the distance is not too far:

The key thing that Elm does here that F# doesn't is that the error message refers to the symbol (issac) where in F# it simply mentions the type (Person).

[isaacabraham]

@jasiozet good to know :-) I think my main worry is that the error refers to the type, rather than the symbol. The type might have been completely inferred - and if for some reason it's the "wrong" type than what you intend, it might be completely misleading. I see this quite often:

1. Error message appears.
2. Initial reaction is "Why is the compiler referring to this type Person? My value is of type Company!" or similar.
3. Eventually realise that the inferred type isn't what you want -> figure out that issue.

Also the fact that you need to read all the way to the end of the error to see the symbol in the message. It's a big disjointed / jarring.

[ericsampson]

Good point Isaac.

How about:

isaac.Fooo does not exist (isaac is of type Person, which does not define a field, constructor or member Fooo)

[jasiozet]

Okay I understand now that if the type is wrong this can be very misleading. That was not clear from the original post (it might be my misunderstanding). I like @ericsampson proposition. Verbose errors are good errors IMO, no need to be succinct there.

It might be worth considering to change "isaac is of type" to "isaac is inferred to be of type", but I'm not sure that's always better.

[Rickasaurus]

Hrm it seems to be pretty clear to me, but you could mention the variable name "isaac" of the type person.

[isaacabraham]

@ericsampson does the reader care about "field / constructor / member" or just "something" :-)

[ericsampson]

Isaac, not really—I just a) wasn’t sure what inclusive term would be both accurate and meaningful to a newer person, b) just copied the original error message as the people who make these messages tend to be on the pedantic/precise side, as language nerds lol.

You could just as easily say …(isaac, which is of type Person, does not define a SOMETHING fooo)

[olivercoad]

Mentioning the variable name (isaac) seems like a nice idea, but there isn't always a variable name, eg. (toPerson "isaac").Fooo). I guess you could have a different message depending on the situation.

@jasiozet good to know :-) I think my main worry is that the error refers to the type, rather than the symbol. The type might have been completely inferred - and if for some reason it's the "wrong" type than what you intend, it might be completely misleading. I see this quite often:

1. Error message appears.
2. Initial reaction is "Why is the compiler referring to this type Person? My value is of type Company!" or similar.
3. Eventually realise that the inferred type isn't what you want -> figure out that issue.

Also the fact that you need to read all the way to the end of the error to see the symbol in the message. It's a big disjointed / jarring.

I don't quite understand the worry here. In the context of the IDE, just by the location of the red squiggle it's obvious what symbols are involved. When I hover to see the error message, the main thing I'm looking for is what type it thinks it is. Seeing the type is what led you to working out that the problem is that it should be type Company.

If you're reading the error message from build logs or problems panel, then I agree it might be nice to include the variable name if available. But I think the type is most important and should be the first thing mentioned.

[olivercoad]

I just a) wasn’t sure what inclusive term would be both accurate and meaningful to a newer person

I think the term "member" is already inclusive of fields and constructors. Not sure what's most meaningful to a newer person though