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 protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
