> On May 6, 2016, at 12:04 AM, Adrian Zubarev via swift-evolution > <[email protected]> wrote: > > Definitely a welcome change from me (+1). But this proposal makes me curious > about the impact on the `AnyObject` protocol? > > let string = "foo" > let nsString = string as AnyObject > nsString.dynamicType // _NSCFConstantString.Type > NSString().dynamicType // __NSCFConstantString.Type // there are two > different types? > > This sample won’t bridge anymore if SE-0083 will be accepted.
Right, you'd need to do NSString(string) as AnyObject to explicitly bridge. > Can we also drop the @objc from `AnyObject` protocol and leave it as an > implicit protocol for classes? (Personally I’d rename `AnyObject` to > `AnyReference` if Swift will introduce other reference types.) The @objc-ness of AnyObject is more or less an implementation detail. On Darwin platforms at least, AnyObject still has the magic ability to dispatch to all @objc methods, similar to `id` in Objective-C, which vaguely defends its @objc-ness. (If we're going to rename it, my own preference would be to drop the Any and just call it `Object`, since we don't put Any in any other protocol names.) > This change might allow the replacement of the `class` keyword from protocols > with the implicit `AnyObject` protocol, which can be discussed in this > thread: Should we rename "class" when referring to protocol conformance? > > One more thing I’d like to ask: is there any possibility of adding a new > `bridge` keyword, which would allow explicit bridging to a different language > type (ObjC, etc. if there are any more languages we can bridge to [C or maybe > one day C++])? > > T `bridge` U > T? `bridge` U? One could write `bridge` as a method in most cases; it doesn't need to be a keyword with special syntax, since you could write `T.bridge(U.self)` (or, if we accept https://github.com/apple/swift-evolution/pull/299, `T.bridge(U)`). Idiomatically, though, we generally use initializers for value-preserving conversions, so U(T) would be more consistent with the rest of the standard library. -Joe > The ugly NSError pattern could be rewritten and migrated to: > > do { > try something() > } catch let error { > handle(error `bridge` NSError) > } > > Is such a change complicated, what do you think? > > -- > Adrian Zubarev > Sent with Airmail > > Am 4. Mai 2016 bei 01:50:54, Joe Groff via swift-evolution > ([email protected]) schrieb: > >> Thanks everyone for the initial round of feedback. I've submitted a draft >> proposal: >> >> https://github.com/apple/swift-evolution/pull/289 >> https://github.com/jckarter/swift-evolution/blob/remove-bridging-conversion-dynamic-casts/proposals/XXXX-remove-bridging-from-dynamic-casts.md >> >> -Joe >> _______________________________________________ >> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
