Design Priorities for the Swift 6 Language Mode

[Jon_Shier]

Not especially, but this isn't really the place. I'm just pointing out that when the community thinks of ecosystem improvements, module resilience isn't what most people envision.

[John_McCall]

Doug's post is about the upcoming Swift 6 language mode. Adding a centralized package registry doesn't require a language mode, so you shouldn't expect any discussion of that here, no matter how interesting or important it might be.

You might have missed it, but we did make a blog post about a month ago talking about more general project priorities and upcoming work, and it does include information about SwiftPM and its work towards a package registry. If you'd like to talk about that, you might participate in the forums thread about that post, or you could find / start a thread in Development > Package Manager.

[Jon_Shier]

I mean, there could certainly be impacts to SPM's Swift 6 mode, but fair enough. Feel free to delete the digression.

[Douglas_Gregor]

@Jon_Shier

The proposal really doesn't say much, but I guess it means what you say:

SwiftPM would then pass each of the upcoming features listed there to the compiler via the -enable-upcoming-feature flag when building a module using this setting. Other targets that depend on this one do not need to pass the features when they build, because the effect of upcoming features does not cross module boundaries.

Yes, that's the intent here. There's currently an open issue to make sure that these aren't treated as unsafe flags.

@Jon_Shier

However, it also says:

Experimental features are still to be considered unstable, and should not be available in released compilers. However, by unifying the manner in which experimental and upcoming features are introduced, we can rely on the same staging mechanisms: a way to enable the feature and to check for its presence in source code, making it easier to experiment with these features. If a feature then "graduates" to a complete, supported language feature, hasFeature can return true for it and, if part of it was delayed until the next major language version, -enable-upcoming-feature will work with it, too.

So how are we to gradually adopt new features if none of the release compilers enable those features?

Are you conflating "upcoming" and "experimental"? "Experimental" are not fully implemented and not reviewed, so one shouldn't depend on them at all and they don't belong in release compilers.

"Upcoming" features are ones that have been reviewed and implemented and can be used with any compiler that supports them. We'll promote a feature from "experimental" to "upcoming" once it's been reviewed, accepted, and implemented.

Doug

[Jon_Shier]

Thanks for the clarity.

[Douglas_Gregor]

@Scott

You're likely purposefully not stating this, but I'll ask anyway since it's been a couple years since the On the road to Swift 6 post was made.

Swift 6 probably still operates under the "it'll be done when it's ready" timeline, so I don't expect any sort of commitment. Is there a vague idea of when Swift 6 might be released? I mean the actual source compatibility break, features will still come in minor releases along the way.

Within a year? Years out still?

Definitely not within the year.

Doug

[davdroman (David Roman)]

@Douglas_Gregor

• For example, Swift's module system might be improved to limit the effect of a module's implementation dependencies on its client modules, making modules and packages more resilient to change.

Is this in reference to this issue? If so, I'm certainly excited for it.

[taylorswift]

@ksluder

You’re asking a technical team to commit to getting into the business of running and maintaining a centralized package repository. That’s not a problem within the scope of SwiftPM tool improvements.

Furthermore, your assertion that the lack of an ordained centralized repository makes Swift “inferior” is highly dubious.

there is a big difference between maintaining a centralized package repository and a centralized package registry.

the latter seems like a very reasonable request, and something that i feel has been sorely missing for quite some time.

[ksluder (Kyle Sluder)]

As @John_McCall said, it’s not a reasonable request in the context of this discussion, which is about language modes.

[John_McCall]

To be clear, I'm not weighing in about the idea itself, I'm just saying it's off-topic in this thread because it doesn't rely on a language mode.

I've been hoping that people would just let it lie, but if it keeps kicking up, I'll move the discussion to a separate thread.

[edudnyk (Eugene Dudnyk)]

Hi.
Can Swift / ObjC interop improvements be the priority for Swift 6 too? There are couple of missing capabilities (1, 2, 3) which can unlock other important developments like deterministic builds with llbuild, and proper ObjectiveC support by SPM.

[David_Smith]

Would those be breaking changes? If not, they could be in Swift 6 but would not be relevant to this thread about the Swift 6 language mode.

[allevato (Tony Allevato)]

@edudnyk

There are couple of missing capabilities (1 , 2 , 3 )

It looks like #3 that you linked is related to SE-0384 that's currently in review, so please make sure to offer any input you have there as well.

[edudnyk (Eugene Dudnyk)]

I don't have enough swift compiler knowledge to estimate if those would be a breaking changes or not, but to my judging, if according to this comment the proper way of supporting ObjC forward declarations is to have an index of ObjC type names in Swift, it may affect the swift module format. Deterministic builds support, if it involves changing the way how and/or where the include paths are stored, might affect the swift module format as well. Parallelization of module loading by lldb might require the change of the module format, too. So it would be great if these issues can be carefully considered and taken into account in terms of

1. what is the vision for the solution to them, and
2. should the solution be prioritized and implemented as a part of the Swift 6 scope.

[xwu (Xiaodi Wu)]

Hi @edudnyk,

This discussion is specifically focused on the Swift 6 language mode.

[David_Catmull]

I suspect I'm not alone in that I'm not entirely sure what a "language mode" is.

[xwu (Xiaodi Wu)]

@David_Catmull

I suspect I'm not alone in that I'm not entirely sure what a "language mode" is.

This is explained in the post itself at length. Indeed, that’s kind of the central point of the post.

I was going to quote some relevant parts of it here but it would end up being just cutting and pasting entire paragraphs, so instead please refer to them above.

The briefest relevant snippet, I suppose, would be that the Swift 6 language mode is:

a targeted set of source-incompatible changes to the language. . . . Most features do not fall in this category, [including] major efforts that are underway . . . such as the ownership model or constant evaluation

[ksluder (Kyle Sluder)]

It’s unclear whether or not the features @edudnyk has described, which seem to have an underlying theme of “build system extensibility”, would need to be confined to a new language mode. Doesn’t that make it in-bounds for this thread?

[David_Catmull]

@xwu

This is explained in the post itself at length. Indeed, that’s kind of the central point of the post.

The original post certainly has lots of details. I just feel like the concept of what a language mode actually is gets lost. Is it a compiler setting? Or a more abstract concept?

[ksluder (Kyle Sluder)]

It’s a compiler setting. It already exists today; that’s how the compiler decides whether to make sendability issues warnings (Swift 5.6 language mode) or errors (5.7 language mode).