(willing to work on part of this if it's a change wanted by the Go community)

@Manishearth I haven't seen any objections to it here so far, IMO it would a nice to have. Please let me know if you'd still like to work on it or I can take over and get it in for Go1.9.
Thanks.

Feel free to take over, I don't have much time right now 😄

Sounds Gucci To Me, thanks!

I've mailed https://go-review.googlesource.com/c/35471.

CL https://golang.org/cl/35471 mentions this issue.

Replied on CL:

Please do not do this with only edit distance. This can lead to comically bad suggestions. The suggestion should only be made if it actually fits in the surrounding code. For example, if the suggestion would cause type errors, it's a bad suggestion and should not be made. It's not clear to me the compiler is set up for that kind of analysis, in which case the suggestions should simply not be made.

One of the things I strongly dislike about clang is its nonsensical suggestions. There needs to be a prior probability assigned to "maybe the thing really is undefined" instead of trying to match it to something that is defined. I got this once, which illustrates the problem with edit distance nicely:

use of undeclared identifier 'deadline_'; did you mean 'readlink'?

No, even though the edit distance is small, no one types deadline_ instead of readlink. No one. Edit distance clearly doesn't capture the typos people actually make.

If we're going to make further changes to suggestions, I would like to see actual data about the kinds of mistakes people make first.

/cc @dr2chase

That's a great point @rsc. While experimenting offline, I noticed the same problem, comically bad suggestions also present in the CL test/fixedbugs/*.go file e.g TOOOOOOOOL -> did you mean Id?.
For sure, I look forward to hearing from @dr2chase and other folks.

TOOOOOOOOL -> did you mean Id?

You need to have a limit on the distance for this to work.

FWIW rustc just uses edit distance with a bound and the suggestions are pretty good. It does no type analysis. Yes, it has its flaws with things like deadline/readlink, but it seems to work pretty ok. I find such cases pretty rare.

The heuristics we use are:

• For struct fields, find field of same struct with closest levenshtein distance, where the maximum allowed distance is the length of the typo string (so at least one char must match)
• For imports (also for macros), we use the default heuristics, which are that the maximum allowed levenshtein distance is the a third of the length of the typo string, or 1, whichever is greater.

Of course the languages are different enough that these heuristics may not be general.