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

[Adrian Zubarev]

> 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 (jgroff at apple.com(mailto:jgroff at apple.com)) schrieb:

>  
>  
> > On May 6, 2016, at 12:04 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> 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 (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
> > _______________________________________________
> > 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/20160509/fe48faaa/attachment.html>