Swift.org blog: New Diagnostic Architecture Overview

Announcements
21

Are there tests for these diagnostics to avoid regression? I tried one of the examples from the blogpost in Xcode Version 11.2.1 (11B53) (only changing the ClosedRange to Range, because apparently ClosedRange doesn't work with ForEach anymore) and it gives me an awful diagnostic. It seems it wants to make 0..<5 a Range<Double> instead of Range<Int>

struct ContentView: View {
    var body: some View {
        ForEach(0..<5) { // Generic parameter 'ID' could not be inferred
            Circle().rotation(.degrees($0))
        }
    }
}

Or maybe that specific diagnostic isn't in Xcode yet?

1 Like
22

Xcode 11.2 ships with Swift 5.1.2, not 5.2.

23

I thought that this diagnostic is already in 5.1.2 because the rest of them is, and you can still get the message from the blog post with a slightly modified code

struct Foo: View {
  let range = 1..<5
  var body: some View {
    ForEach(range) {
      Circle().rotation(.degrees($0)) // Cannot convert value of type 'Int' to expected argument type 'Double'
                                      // Replace '$0' with 'Double($0)'
    }
  }
}
1 Like
24

Fantastic work! Both the article and better diagnostics are really cool, thank you!

I had a few questions about the article where I thought things might be wrong or could be tweaked:

First round and the Approach

References to the second argument in str + 1 not conforming to ExpressibleByIntegerLiteral should either be the first argument or ExpressibleByStringLiteral right?

Missing Members

In Missing Members func foo() -> A is probably meant to be static so .foo would work.

Argument-to-Parameter Conversion Mismatch

cannot convert value of type 'UInt' to expected argument type 'Int'

Then it tells the user to fix it by casting y to Int.

How do you know it’s better to convert one argument to UInt or the other to Int? There’s trade offs either way ($0 < 0 or Int.max < $0 <= UInt.max). Negative values are probably more likely, but the use of UInt might imply they’re never really negative (like array indices). The code could also be written to work in both cases.

Is it better to make these fixes more like suggestions? I think this is better than suggesting to the user that the shortest path to get it to compile fixes all the problems, wdyt?