On: New Diagnostic Architecture Overview

[pohl]

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

[wwalexander → pohl]

I’ve noticed that when editing the ContentView in SwiftUI, errors will sometimes be attached to a totally unrelated line (OTOH, forgetting to unwrap an optional returned by NumberFormatter.string() showed

    type of expression is ambiguous without more context

on a straightforward Text() expression halfway up the file). The only way to find the actual source of the error is to undo every change until the error disappears, and coupled with sluggish compilation times this becomes a real pain. I hope they address this issue as part of their improvements.

[msbarnett → wwalexander]

This is literally given as an example in the article. No hope required.

[wwalexander → msbarnett]

Oh wow, you’re right, at the very top. Skimmed right over that. Thanks for pointing it out.

I guess SwiftUI exacerbates the problem since expressions are necessarily very deeply nested.

[msbarnett → wwalexander]

The last example in the SwiftUI section is also an “ambiguous type expression” example with a fairly complex nested view.

It seems to be a problematic diagnostic they have particularly focused on resolving.

[xedin → pohl]

Yes, SwiftUI diagnostics in particular are going to benefit from these changes.

[msbarnett → pohl]

The article gives several examples of areas in which these changes have particularly made big improvements to common error messages one might see while working with SwiftUI

[bobbylarrybobby → pohl]

Did you read the article?

[dang → bobbylarrybobby]

"Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that.""

https://news.ycombinator.com/newsguidelines.html