Any Keyword for static variable

Using Swift
1

is it a bug?

protocol Pro {}

struct Base: Pro {}

let x: any Pro = Base()
struct ST {
    static var val: any Pro? // 'any' has no effect on concrete type 'Pro?'

    static func set(_ val: any Pro) {
        self.val = val
    }
}

I got this error:

/home/carlhung/swiftProjects/playground/Sources/playground/main.swift:21:21: error: 'any' has no effect on concrete type 'Pro?'
    static var val: any Pro? // 'any' has no effect on concrete type 'Pro?'
2

The way that any binds to the type coming after it, any Pro? is parsed as any Optional<Pro>, and Optional<Pro> is a concrete type containing any Pro value or nil. Instead, if you want to optionally store any Pro, you'll need to wrap any Pro in parentheses: static var val: (any Pro)?

1 Like
3

thanks

4

This error should come with a fix-it and a more customized message, I think. Unfortunately, at least during this transition phase where P? is accepted, any P? is taken to be a synonym for any (any P)? and the error is particularly confusing.

Recalling that we debated whether we should make any P? do the "intuitive" thing or whether we should aim for consistency in precedence, I think users are likely to have this question both during this transition phase and after bare P? is no longer accepted, so any diagnostic QoL improvements here are going to be worthwhile. But certainly today, while any is new and the error is confusing, it'd be really helpful to give users good guidance here.

cc @hborla

9 Likes
5

I fully agree. I was trying to add some any today, and I could not solve the Optional puzzle. I just thought the feature was incompletely implemented, and moved on (since any is not required).

On the other way, the proposal was perfectly clear for meta types, so it helped me solving the any P.Type vs (any P).Type puzzle.

We just need explicit help for optionals.

I just thought the feature was incompletely implemented

This should raise an alarm to people in charge. There are more and more holes, and it's difficult to know why some syntax won't work as expected. It may be a programmer error, or just the sign that language developers did not finish their job. There are more and more signs that the language is stuck in a beta phase.

7

adding this to my list of fake-deep swift interview questions…

3 Likes
8

If it’s easier to spell a metatype existential than an optional existential, I think the design has optimized for the wrong use case.

I’m tempted to define my own struct Any<T> and play around with the ergonomics.

9

I think Swift now has its own “most vexing parse”.

10

@carlhung, can you elaborate on why you’re adopting any here?

11

Because as I heard in swift 6. It is going to have an error when using existing type without marking “any”. So, it better adopts on my current as soon as possible. Reduce fixing it in the future.

12

I completely agree that all errors about any should come with a fix-it (whether that's to remove the any or add parenthesis where appropriate). There's been a lot of active work on diagnostics QoL for any:

...and I have more improvements on my todo list.

I've also recieved a lot of feedback already about (any P)? and I'm completely open to amending the proposal to make any P? just work the way everyone expects it to work.

12 Likes
13

IMO, we should make sure that some P? and any P? are in sync with respect to this. The same intuitions apply to both, and there should be no reason that switching from an existential to an opaque type or vice versa occasions addition of parens.

11 Likes
14

In the meantime, I've added a tailored error message with a fix-it to turn any P? into (any P)?: [5.7][Type Resolution] Emit a tailored diagnostic for the incorrect `any P?` syntax. by hborla · Pull Request #42282 · apple/swift · GitHub

Thanks for the feedback here, and please let me know if you run into other confusing error messages involving any!

4 Likes