> Right, you'd need to do NSString(string) as AnyObject to explicitly bridge.
Okay great I'm fine with that. :) > 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.) Did I miss something again? I checked SR-0006 and it still has protocols like `Any`, `AnyIterator` or `AnyCollectionProtocol`. -- Adrian Zubarev Am 9. Mai 2016 um 21:38:22, Joe Groff ([email protected](mailto:[email protected])) schrieb: > > > > 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
