I'd prefer to still allow the old signature, and raise either a deprecation warning, or introduce a new warning type. This would ensure you don't have to make all the changes the minute a new version of Swift/Xcode is released, without having to stick to an older version of the language itself. It's just the name after all.
Having a separate warning type for these would allow to easily hide (or disable) them while working on a more urgent issue first, or to hide these purely cosmetic warnings in CI builds.
It wouldn't have to be limited to the Swift 4 timeframe either but could provide a smooth transition whenever needed, similar to how it's done with the SDK updates, too.
On 07.08.2016, at 10:00, Georgios Moschovitis via swift-evolution <email@example.com> wrote:
Right. We’ll have some limited ability to do source breaking changes in Swift 4, but we need to figure out how the mitigation strategy will work (in full detail) so we know exactly what sort of changes will work.
What about having additional source-breaking changes (like the one pitched here) in Swift 3.x versions?
swift-evolution mailing list