[swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

[Adrian Zubarev]

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. 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.)

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?

Wouldn’t this move the bridging mechanism to its own area?

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 (swift-evolution at swift.org) 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
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160506/cfb015a8/attachment.html>