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.
As @John_McCall said, it’s not a reasonable request in the context of this discussion, which is about language modes.
1 Like
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.
5 Likes
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.
2 Likes
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.
1 Like
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.
3 Likes
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
- what is the vision for the solution to them, and
- should the solution be prioritized and implemented as a part of the Swift 6 scope.
I suspect I'm not alone in that I'm not entirely sure what a "language mode" is.
7 Likes
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
1 Like
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?
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?
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).
2 Likes
That's what I suspected, but I wasn't totally sure. Thanks.
One thing I'd love to see addressed in Swift 6 is C-interop, particularly concerning pointers to forward-declared structs, known in Swift only as OpaquePointer.
Losing all the type info for C APIs that use this pattern (which are, in my limited experience, rather common) makes working with them rather annoying.
This blog post describes the situation in more detail.
The blog post also says changing this would be both API- and ABI-breaking, so I'm not sure this is actually addressable even in a new language mode, but I thought I'd bring it up in case folks agree this is worth the API break and we can find some way to avoid breaking ABI.
8 Likes
Might the ongoing C++ integration work benefit this?
That's certainly something that would require a new language mode, and as you note we'd have to navigate the ABI challenges as well as the source incompatibility. That said, I think this is something that could be considered for Swift 6.
Doug
10 Likes
This isn't quite accurate. The compiler setting (SWIFT_VERSION or Swift Language Version in Xcode, -swift-version to the compiler) only supports 4, 4.2, and 5 at this time. Things like the changes you mention (sendability warnings) are gated by compiler version (you get the new warnings using the new compiler), not the compiler's Swift version setting. IIRC, the Swift 6 compiler will move to supporting 5 (or perhaps a later version like 5.8) and 6 as language "modes", with all of the new behavior enabled under the 6 mode.
For sendability errors, the level of checking is controlled by the SWIFT_STRICT_CONCURRENCY setting (or whatever the command line equivalent is) as well as other compiler flags. And like I said, it also changes between compiler versions as the rules are refined.
@Jon_Shier, there is no need to speculate or recall from memory: the original post spells out the correct answer about Sendable checking and future language mode support explicitly—
1 Like
I’m the one who incorrectly recalled from memory.