Ah, we definitely will do that in Swift 4 mode no matter what approach is chosen here, since Swift 4 Is The Future. We also currently do that but in reverse for Swift 3 mode, using `@available(swift, introduced: 4)`.
Jordan > On Apr 20, 2017, at 17:09, Philippe Hausler <phaus...@apple.com> wrote: > > I see your conundrum here! Thats definitely a gnarly issue - I would say the > preferred way seems much more to the C name of the symbol, but that does have > a problem that might be possible. In your example the swift 4 name was > Notification.Identifier, that would mean that it is possible for a developer > to use then the old name somehow. Is this something we should watch out for? > Specifically I am more so interested if it is something we should watch out > for overlay development. > > Per your idea about the type alias, shouldn’t we have an effective > > @availability(swift, obsoleted: 4.0) > typealias NSNotification.Name = Notification.Identifier > > To prevent source compatibility issues? > >> On Apr 20, 2017, at 16:55, 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. >> - 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. >> >> What do people think? >> >> Jordan >> _______________________________________________ >> swift-dev mailing list >> swift-dev@swift.org <mailto:swift-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-dev >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
