lystn

Swift has evolved since 1.x to have a fluctuating amount of magic/implicit bridging from ObjC and Foundation types, sometimes going in the opposite direction towards very explicit type conversions. We've started seeing more of what the "steady state" looks like as Swift 3.x/4.x development matures. In the early days, Swift users would need deep compiler internal implementation details to know which NSNumber-representable type could implicitly convert. As of SE-0139 that's a lot clearer. The subtleties of unenforced protocol conformance semantics: https://oleb.net/blog/2016/12/protocols-have-semantics/ Proposals on bridging New from Doug Gregor, limiting @objc inference: https://github.com/DougGregor/swift-evolution/blob/objc-inference/proposals/NNNN-objc-inference.md NSNumber and NSValue: https://github.com/apple/swift-evolution/blob/master/proposals/0139-bridge-nsnumber-and-nsvalue.md Optional to payload or NSNull: https://github.com/apple/swift-evolution/blob/master/proposals/0140-bridge-optional-to-nsnull.md ObjC lightweight generics: https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md Import id as Any: https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md NSError bridging: https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md Fully eliminate implicit bridging: https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md Remove bridging conversion behavior from dynamic casts: https://github.com/apple/swift-evolution/blob/master/proposals/0083-remove-bridging-from-dynamic-casts.md Ole Begemann on "Protocols are more than Bags of Syntax": https://oleb.net/blog/2016/12/protocols-have-semantics/ No protocol for non-user constructable types (e.g. library-vendored types) :( Conventions are useful, even if not for technical reasons. Case study with Realm trying to buck NSError ObjC conventions: https://github.com/realm/realm-cocoa/pull/1123