[Accepted] SE-0364: Warning for Retroactive Conformances of External Types

Hello, Swift community.

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.

Steve Canon
Review Manager


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.

1 Like