New Diagnostic Architecture Overview (swift.org)

This is really great, as Swift’s error messages aren’t great when working with anything moderately complex. SwiftUI in particular seemed to stretch the abilities of the type system to the breaking point, and I’m glad to see that work is being done to improve error messages there instead of failing with mystifying reasons when people make reasonable mistakes.

Compiler errors in SwiftUI have been especially unhelpful. Is this something that this effort is intended to improve?

    type of expression is ambiguous without more context

I'm really happy to see this effort! I participate in the rustc project dedicating myself mainly to diagnostics and ergonomics and I believe that the industry hasn't scratched the surface of what can be done through error messages. In Rust, my own personal rule of thumb is that the compiler should be your first tutor and act as a pair programmer. Rust has one advantage for doing so that was arrived to "by accident": the fewer things are valid code, the bigger the distance between valid and invalid code. In the boundary of these two areas there is code that can be reasonably imagined to be valid by somebody who knows a fraction of the rules of the language. I call this the "negative space" of the language. You can think of a case (again, in Rust because it is what I am familiar with, but the ideas can be applied to any language) like

    fn main() {
        let x = "a" + "b";
    }

which is invalid Rust due to reasons, but the compiler emits the following output[1]:

    error[E0369]: binary operation `+` cannot be applied to type `&str`
     --> src/main.rs:2:17
      |
    2 |     let x = "a" + "b";
      |             --- ^ --- &str
      |             |   |
      |             |   `+` cannot be used to concatenate two `&str` strings
      |             &str
    help: `to_owned()` can be used to create an owned `String` from a string reference. String concatenation appends the string on the right to the string on the left and may require reallocation. This requires ownership of the string on the left
      |
    2 |     let x = "a".to_owned() + "b";
      |             ^^^^^^^^^^^^^^

Is it perfect? No, it is verbose and you could make the case that the language should be extended to accept the code as is. Because we have design constraints that don't let us accept the code, we've extended the compiler to support the construct in order to provide the fixed code, while simultaneously allowing the language to conform to its constraints. The hard part of this is that now your compiler is as complex as it would have to be to support the superset language. Also, the less negative space there's in the language, namely, the more expressive it is, the less you can apply this strategy

I am reminded of a recent tweet: "We spent decades trying to invent a sufficiently smart compiler when we should have been inventing a sufficiently empathetic one"[2]

Edit: if you have to Google to understand what the compiler is saying, I consider that a bug. File tickets for confusing diagnostics!

[1]: https://play.rust-lang.org/?version=nightly&mode=debug&editi...

[2]: https://twitter.com/mostlysafe/status/1176170363266449410

   ~~~ ^ ~

       ^

    @inlinable public static func + (lhs: String, rhs: String) -> String
                                  ^

    public static func + (lhs: Int, rhs: Int) -> Int
                       ^

This is an awesome article and great learning opportunity.

The article describes the mental model needed to understand the operation of the swift type error diagnostic system with a high level of clarity.

Thinking through how this system works provides a super valuable learning experience for a wide audience of readers.

The diagnostic improvements are great. Unfortunately many of these examples show how serious of a mistake it was to require explicit numeric conversions all over the place.