That seems fair. Imported names are much more likely to experience name churn for prettier APIs, and I’d hate to burden the solution for library evolution with this frequent case. I was hoping it could fall out from whatever the general solution was for library evolution.
> On Apr 21, 2017, at 10:55 AM, Jordan Rose <jordan_r...@apple.com> wrote: > >> >> On Apr 20, 2017, at 18:25, Michael Ilseman <milse...@apple.com >> <mailto:milse...@apple.com>> wrote: >> >>> >>> On Apr 20, 2017, at 4:55 PM, Jordan Rose via swift-dev <swift-dev@swift.org >>> <mailto:swift-dev@swift.org>> wrote: >>> >>> TLDR: Should we just always import C/ObjC types under their Swift 4 names, >>> and use typealiases in Swift 3 mode? >>> >>> --- >>> >>> Hi, swift-dev. As my recent PRs have probably indicated, I've been working >>> on the problems that can come up when mixing Swift 3 and Swift 4 code. Most >>> of these problems have to do with C/ObjC APIs that might present themselves >>> differently in Swift 3 and Swift 4, using the "API notes" feature in our >>> downstream branch of Clang, and a good subset of these problems have to do >>> with types getting renamed. (This includes being "renamed" into a member, >>> such as NSNotificationName becoming (NS)Notification.Name in Swift.) >>> >>> What's the problem? Well, there are a few. First of all, an API defined in >>> terms of the Swift 3 name should still be callable in Swift 4. As an >>> example, let's pretend NSNotification.Name was going to be renamed >>> NSNotification.Identifier in Swift 4. >>> >>> // Swift 3 library >>> public func postTestNotification(named name: NSNotification.Name) { … } >>> >>> // Swift 4 app >>> let id: Notification.Identifier = … >>> postTestNotification(named: id) // should work >>> >>> This means the reference to "NSNotification.Name" in the library's >>> swiftmodule needs to still be resolvable. This isn't too bad if we leave >>> behind a typealias for 'NSNotification.Name'. I have a reasonable (but too >>> broad) implementation at https://github.com/apple/swift/pull/8737 >>> <https://github.com/apple/swift/pull/8737>. >>> >>> That just leads us to another problem, though: because Swift functions can >>> be overloaded, the symbol name includes the type, and the type has changed. >>> The Swift 3 library exposes a symbol >>> '_T03Lib20postTestNotificationySo14NSNotificationC4NameV5named_tF', but the >>> Swift 4 client expects >>> '_T03Lib20postTestNotificationySo14NSNotificationC10IdentifierV5named_tF'. >>> >>> My planned approach to combat this was to use the C name of the type in the >>> mangling, producing >>> '_T03Lib20postTestNotificationySo18NSNotificationNamea5named_tF'. This is >>> prototyped in https://github.com/apple/swift/pull/8871 >>> <https://github.com/apple/swift/pull/8871>. >>> >>> >>> At this point Slava pointed out I was chasing down a lot of issues when >>> there's a much simpler solution for Swift 4: when importing types, always >>> use the Swift 4 name, and use typealiases to handle Swift 3 compatibility. >>> This defines both of the previous issues away, as well as any more that I >>> just haven't thought of yet. >>> >>> There are some downsides: >>> - We currently keep people from using Swift 4 names in Swift 3 code, and we >>> wouldn't be able to do that, since the actual declaration of the type >>> always needs to be available. >> >> I don’t know if this is an important distinction to worry about. That code >> will still be able to use features from Swift 4, and perhaps even Swift 4 >> only types (e.g. Substring from SE-0163). >> >>> - We'd probably want to tweak the "aka" printing in diagnostics to not look >>> through these typealiases. That's not hard, though. >>> - We can't keep doing this once we have ABI stability. Hopefully framework >>> owners aren't going to continue changing Swift names of types, but we'll >>> probably need to implement my "C name in the mangling" plan anyway, just in >>> case. >>> >> >> Would this fall under the realm of library evolution, wherein name changes >> should be versioned? In that case, would we need both symbols whether they >> came from C or not? > > I suspect we'll end up doing my appended follow-up for this: "mangle me as if > my name were ___". That doesn't cover everything the importer does, though > (turning enums into structs, swift_wrapper, import-as-member, etc). > > I also hope we just don't have to deal with name changes very often in > Swift-land. > > Jordan
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
