Status of ExistentialAny

[alanzeino]

I was just migrating our codebase to support MemberImportVisibility when I noticed that the ExistentialAny page mentions "This will become the default in a future language mode.":

Documentation

For context, we have approximately 49k protocol definitions in our Swift codebase, so doing a migration to add missing any keywords where needed may be a bit of a large effort. We also use warnings-as-errors.

Is it still on the roadmap to make this flag the default? Should we start this migration now and save ourselves some time down the road, or wait, in case the flag will work differently?

[Cyberbeni (Benedek Kozma)]

It's already the default in Swift 6 mode.

[xwu (Xiaodi Wu)]

Not so:

@hborla

The Language Steering Group has decided that one previously-accepted upcoming feature, ExistentialAny, will not be enabled by default in Swift 6. SE-0335: Introduce existential any introduces the any keyword to identify existential types. The proposal also specifies that "bare" protocol names will no longer be permitted as types---they must either use any or some, as appropriate---under the upcoming feature flag ExistentialAny. Given the concerns about migration to consistent use of existential any in the language, and the expectation that additional language improvements will be coming that might affect the end result of that migration, the Language Steering Group is deferring the source-incompatible changes in SE-0335 to a future language revision.

If it were my codebase, I wouldn't devote a large effort to devising your own processes and infrastructure to migration existing uses at this point. It's well understood that requiring ExistentialAny across the board would benefit from some sort of migration tooling or at least better guidance.

Now, if you truly need the dynamism of any, I doubt you'll regret using the new syntax going forward. But part of the benefit to users of requiring ExistentialAny is that we (or some of us) surmise that a fair amount of existential usage doesn't actually require the dynamism and could be replaced with generics or opaque types more performantly—put another way, we think having P mean any P encouraged users to write less optimal code by default.

It would therefore be self-defeating if we simply encouraged everyone to mechanically sprinkle any everywhere in their codebases. So we deferred switching ExistentialAny to be on by default until we could have a chance to think through what a smarter migration path would look like and what additional language features or migration tooling that might involve.

[johnno1962 (John Holdsworth)]

There was some discussion of migration tools in this thread Existential Any migration Script - #14 by johnno1962. I personally think it is time this proposal was formally withdrawn to avoid confusion. It can always be re-introduced at a later date.

[Slava_Pestov]

@xwu

Now, if you truly need the dynamism of any, I doubt you'll regret using the new syntax going forward. But part of the benefit to users of requiring ExistentialAny is that we (or some of us) surmise that a fair amount of existential usage doesn't actually require the dynamism and could be replaced with generics or opaque types more performantly—put another way, we think having P mean any P encouraged users to write less optimal code by default.

Also for this exact reason, I would recommend that when starting a new project, users consider always enabling ExistentialAny. :) In my opinion, seeing the relationship between existentials and generics made explicit at the syntactic level makes the trickier parts of the language easier to reason about, and in the worst case where everything is any anyway and you don't end up wanting generics, it's just a few more keywords here and there than before.