I think this is very interesting, and in line with other work I'm doing on warning suppression. If anybody else is interested, by all means step up, otherwise I don't mind holding onto this one. I won't be able to tackle it for a couple weeks at the very least, though.

There are several directions we can go here. @jckarter has pointed to some of the awesome things Elm does.

Much of that link seems to talk about what we already have, such as hints, reproducing and underlining the offending code, and colors. But they do show more details on failure, which could be an interesting direction to go further in, and they do show more type inference steps.

Better type-checking diagnostics is definitely a hugely valuable request, though I think Daniel was more so asking for a unique identifier for every warning, such that warnings are searchable/googlable. Then, we could have a lookup (online, or offline) on that identifier. Perhaps if we had a long-form description of each warning, mapped to the unique identifier, we could generate documentation (either on website or in error message themselves via some kind of --verbose-warnings) from them. Having a unique name/identifier would also be useful for finding relevant blog posts online, etc.

That is true, I would of course also love to see that documentation integrated better with the compiler. Having the facility for presenting the advanced documentation inline, or doing more sophisticated diagnostics UI (like pretty printing with syntax coloring the code in question with additional "advanced" explanation type stuff) would be awesome.

Comment by Owen Voorhees (JIRA)

Opened a PR here for stable diagnostic IDs to address the first half of this: #27299

Comment by Owen Voorhees (JIRA)

Educational notes are now available on master to address the compiler-integrated documentation aspect of this. So far we haven't introduced unique identifiers for diagnostics, but I think it makes sense to track that separately if we decide they would still be nice to have for stack overflow, google, etc. I'm going to mark this as resolved, but feel free to reopen if you disagree.

I'm tracking documentation coverage in https://bugs.swift.org/browse/SR-12509