The second review of SE-0364 ran from April 25th through May 9th. The second review was narrowly focused on the @retroactive spelling for qualifying such conformances.
Feedback was generally light. There were questions about whether it should be required even for conformances that do not cross a resilience boundary (yes, the issue being addressed is present even without a resilience boundary being involved), the naming (@retroactive is a somewhat niche term of art, but the LWG believes that it's meaning is clear enough once the user is introduced to it, and no better term has presented itself), and whether this should apply at module or package boundaries.
In our discussion, the LWG clarified that this will be required for cross-import overlays, which are a "separate module" from the standpoint of the Swift compiler, even though this is the only place that such a conformance can actually be declared. While we might look into modifying these rules in the future, this actually brings the source language in line with the current ABI, where such conformances are tagged as retroactive by the compiler.
Right. It should be a goal of formalizing cross-import overlays in the language (they're currently an unofficial feature) that we have enough information to know that the overlay is a unique union point for the two modules and thus not consider any cross-import conformances in them to be formally retroactive. However, we don't currently have that information in the unofficial feature, and even if we add it, we will need the ability to still treat those conformances as retroactive, at least to the extent of preserving ABI details like conformance mangling.
Thanks for maintaining Swift and keeping it safe by design and enjoyable to write code on
I have a couple of questions regarding this proposal. The proposal is quite informative on the nature and motivation of the changes. However, it lacks actionable steps for developers to resolve this warning, other than adding @retroactive to suppress it.
I do not think suppressing the warning is the intended behavior, but considering the usual tight schedules and pressure from the product team, many developers might be tempted to do just that.
To help developers properly adopt this warning, it would be beneficial to add more robust examples to those provided in the proposal. For instance, creating wrapper structure to confirm protocol instead or any other way you feel will be appropriate.
This will become quite relevant due to the global migration to Swift 6.
Thank you
// Not a great implementation, but I suppose it could be useful.
extension Date: Identifiable {
public var id: TimeInterval { timeIntervalSince1970 }
}
