Mark ExistentialAny and InternalImportsByDefault as Implemented for Swift 7.0

[MahdiBM]

The language steering group has decided to not release these in Swift 6.0.
https://github.com/apple/swift/blob/20f0353f2b65094089c8df3545b8036ceb189507/include/swift/Basic/Features.def#L220

[xwu]

Sorry, these changes aren't accurate, and the fields are correct as-is: These proposals describe features that are implemented and usable in the compiler versions as indicated. For example, you can write internal import Foundation as of the Swift 6.0 nightlies, and you can write any Equatable as of Swift 5.6.

Only source-breaking changes, a portion of each proposal, are gated behind an upcoming feature flag. As indicated by the absence of any notation to state that they are enabled by default in Swift N, it has not yet been determined when that will occur. At a later time, we can update that field to indicate that the source-breaking changes are to be enabled by default in such-and-such language mode; there is currently no such thing as Swift 7 (either compiler version or language mode).

[MahdiBM]

@xwu fine by me, I only was forced to create a PR instead of an issue to be able to actually discuss this, considering this repo does not accept issues.

Perhaps we can have a new field like "Planned For: Swift 7"? Even Paul Hudson couldn't figure out what Swift version these will be enabled in, and I don't expect anyone to know these info unless they keep track of the language changes quite closely, or bother enough to look them up in the source files.

[xwu]

It's not surprising that no one would be able to figure out when these flags will be turned on by default--there is no answer as we haven't made a decision yet! If desired we should have some way to indicate that though.

[MahdiBM]

Hmm alright. But clearly something is not quite right here.

Let me put it this way.

Can the proposal use better language as to not confuse readers that the features are supposed to be enabled by default in Swift 6?

[xwu]

Sure, it seems fine to write exactly that: "not enabled by default in Swift 6 language mode".

[dempseyatgithub]

This issue is what PRs #2370, #2383, and #2384 (and others which have already been committed) are intended to address.

The Upcoming Feature Field will include both:

• the version it is implemented in (if different than when the proposal was implemented)
• the language mode when that feature is always enabled

If there is no 'always enabled' annotation the feature is not automatically enabled in any announced Swift language mode. Just like it has been since the introduction of Upcoming Feature Flags.

These fields are included in the updated Swift Evolution dashboard metadata schema, although, of course, they depend on the PRs containing the correct metadata being merged.

The metadata proposal details what each annotation means:
https://forums.swift.org/t/swift-evolution-metadata-proposed-changes/70779#add-support-for-upcoming-feature-flags-16

The metadata transition plan details that until the proposals adopt the new annotations, as in those PRs, the correct information won't be in the metadata.
https://forums.swift.org/t/swift-evolution-metadata-transition/71387#upcoming-feature-flag-9

My thought had been that since WWDC week is an incredibly busy week, including labs, etc. and a lot of time and effort prepping releases, etc. that these were not as high a priority as other items.

My plan had been to circle back around after WWDC to follow up on these.

But there has been a large amount of time and consideration of how to represent these and a plan is in place to do so. But it didn't happen before WWDC.

[dempseyatgithub]

Note also that there is a difference between when a proposal is implemented in a release, and which language mode in which the source-breaking changes are enabled.

For example:

The Existential Any proposal was implemented in 5.6 as the proposal currently says. You can use 'any XXXX' in code since 5.6.

What is gated by the upcoming feature flag is the source breaking change of requiring 'any' when used with an existential type.

So, it would be wrong to change the implementation version of that proposal.

What the LSG decided is that they would not enable the breaking change in Swift 6 language mode. Not that they have pulled using 'any' out of the language.

I don't have the time until next week to look into the detail of the other proposal, but similarly, Upcoming Feature Flags are only flags to turn on breaking changes, they very rarely completely turn off an entire proposal.

[MahdiBM]

@dempseyatgithub I think you're right on all fronts, and i understand that the current changes in this PR as of writing this comment are not quite right.

If there is no 'always enabled' annotation the feature is not automatically enabled in any announced Swift language mode. Just like it has been since the introduction of Upcoming Feature Flags.

This is the problem IMO. This should be more clear and the proposal should say something more clear. I understand that something like "Planned for: Swift 7.0" might not be 100% accurate, but it's the most concise wording that I can think of, and i think in reality it'll still end up being accurate. After all, If you don't plan on release a feature at all, why would you add it to the language in the first place?!

We could also try to explain the same thing in a whole sentence, but i think what i proposed above is good enough since it has enough accuracy and it's much more concise.

[dempseyatgithub]

I think once the intended annotations are added, it becomes clearer.

The flag is valid and enables the breaking change until the language mode where it is marked as obsoleted. (i.e. the feature is always enabled, therefore the flag is obsolete)

Just like most API doesn't require a special annotation to indicate it is still valid release after release. Only the important milestones are notes - when it becomes available, when it becomes deprecated or obsoleted.