some View? without parentheses in Swift 6.4

Every SwiftUI developer has typed this at least once.

func badge(for user: User) -> some View? {  // error
    guard user.isVerified else { return nil }
    return Image(systemName: "checkmark.seal.fill")
}

It looks right. Int? is an optional Int, so some View? should be an optional some View. But the compiler rejects it, and the fix has always been a pair of parentheses.

func badge(for user: User) -> (some View)? {
    guard user.isVerified else { return nil }
    return Image(systemName: "checkmark.seal.fill")
}

The same thing happens with any. A delegate property is the classic case.

weak var delegate: any ScannerDelegate?    // error
weak var delegate: (any ScannerDelegate)?  // ok

SE-0521, introduced in Swift 6.4, makes the version without parentheses mean what we thought it meant all along.

func badge(for user: User) -> some View? { ... }

weak var delegate: any ScannerDelegate?

Why some View? used to fail

The problem was precedence. In Swift's type parser, ? binds tighter than some and any. Written out, the order was:

?  >  ~  >  &  >  some / any

some and any sit at the bottom, so they take everything to their right. That means some View? was read as some (View?), not (some View)?.

And View? is Optional<View>. The thing after some or any has to be a protocol, and Optional is a struct. So the compiler rejected it — not because the type made no sense, but because the parser grouped it the wrong way.

There was no competing meaning to protect. The proposal points out that no future version of Swift would ever want some P? to mean anything other than "an optional of something that conforms to P". The parentheses were only there to keep the parser happy.

You can easily support sarunw.com by checking out this sponsor.

AI Grammar: Correct grammar, spell check, check punctuation, and parphrase.

Try it for Free

What works now

The parser now lifts a trailing ? or ! up so it covers the whole some/any type.

some View?                 // (some View)?
any ScannerDelegate?       // (any ScannerDelegate)?
any ScannerDelegate!       // (any ScannerDelegate)!
any (Codable & Sendable)?  // (any Codable & Sendable)?
any ~Copyable?             // (any ~Copyable)?

The old spelling is not going anywhere. (some View)? and some View? are the same type, down to the mangled name, so there is nothing to migrate and no ABI concern.

What still needs parentheses

A protocol composition is the one case that stays an error.

any Codable & Sendable?    // error, with a fix-it to add parentheses
(any Codable & Sendable)?  // ok
any (Codable & Sendable)?  // ok

The parser could read the first one the same way, but a ? at the end of a long composition is easy to misread, so the proposal asks for the parentheses instead. It notes the rule can be loosened later without breaking any code.

Why this matters now

This would be a nice-to-have on its own. It becomes more than that because of where Swift is going.

Swift is moving toward requiring any on every existential type. Today var delegate: ScannerDelegate? compiles with no complaint. Under the ExistentialAny upcoming feature it warns, and in a future language mode it will be an error.

Think about what that migration looked like before this proposal. Every optional protocol-typed property in a codebase — every delegate, every data source — would need an any and a pair of parentheses.

var delegate: (any ScannerDelegate)?
var dataSource: (any FeedDataSource)?
var footer: (any View)?

That is a lot of parentheses for no reason other than a parser rule.

The compiler's fix-it reflects the change. With -enable-upcoming-feature ExistentialAny, this line:

let x: P?

warns that P must be written any P, and the fix-it used to replace it with (any P)?. Now it writes any P?. That applies when the existential is a single protocol, not a composition, and is optional or implicitly unwrapped.

So when the day comes to add any everywhere, the code that comes out the other side reads the way we would have written it by hand.

You can easily support sarunw.com by checking out this sponsor.

AI Grammar: Correct grammar, spell check, check punctuation, and parphrase.

Try it for Free

Summary

Swift 6.4 lets a trailing ? or ! cover a whole opaque or existential type, so some P? means (some P)? and any P? means (any P)?. A protocol composition still needs its own parentheses, written any (P & Q)? or (any P & Q)?. The old parenthesized spelling stays valid and gives the identical type, so nothing needs to change today. It pays off later: when any becomes required for existentials, the fix-it will write any P? rather than (any P)?.