(Further) Improvements to diagnostics around 'some' types

Hey, all! In https://github.com/apple/swift/pull/25624 I put in some improvements for some of the more obscure diagnostics about opaque types.

var opaque = foo()
opaque = bar() // expected-error {{cannot assign value of type 'some P' (result of 'bar()') to type 'some P' (result of 'foo()')}} {{none}}
opaque = () // expected-error {{cannot assign value of type '()' to type 'some P'}} {{none}}
opaque = computedProperty // expected-error {{cannot assign value of type 'some P' (type of 'computedProperty') to type 'some P' (result of 'foo()')}} {{none}}
opaque = SubscriptTest()[0] // expected-error {{cannot assign value of type 'some P' (result of 'SubscriptTest.subscript(_:)') to type 'some P' (result of 'foo()')}} {{none}}

That's definitely an improvement over what happened before, and the fix applies generally, any time an opaque result type shows up directly in a diagnostic. But is there more we can or should do? (For example, we could show notes pointing to where the various some types come from, but I'm worried about a deluge of notes if a diagnostic already has notes.)

By the way, there's a set of known issues already in there:

var opaqueOpt: Optional = opaque
// FIXME: It would be nice to show the "from" info here as well.
opaqueOpt = bar() // expected-error {{cannot assign value of type 'some P' to type '(some P)?'}} {{none}}
opaqueOpt = () // expected-error {{cannot assign value of type '()' to type '(some P)?'}} {{none}}

This gets tricky, though, because the entire type is no longer the "result of" a function; just part of it is. And what happens if you manage to have a type with multiple opaque result types in it? (Dictionary<some Hashable, some Any> is a type that can be constructed, for example.)

So. Thoughts?

cc @Joe_Groff, @xedin

2 Likes

Off the top of my mind - we need to make sure that all of the unsupported uses are properly diagnosed as well as some of the contextual failures like argument/parameter conversions e.g. https://bugs.swift.org/browse/SR-10852

If we’d like to avoid emitting too many notes in the common case, at some point maybe we could introduce an ‘enable verbose type descriptions’ compiler flag. In addition to enabling notes pointing to the origin of opaque types, it could also do things like disable type trimming if we introduce that as described in https://bugs.swift.org/browse/SR-1029 . The obvious problem with hiding this behind a flag is discoverability, but maybe tooling could help with that.

1 Like
Terms of Service

Privacy Policy

Cookie Policy