Re: [swift-evolution] [Review] SE-0116: Import Objective-C id as Swift Any type

> On Jul 8, 2016, at 11:19 AM, Ben Langmuir wrote: > > Hey Joe, Sorry Ben, missed this when you sent it a couple weeks ago. > I’m +1 on the overall direction, but I have some questions/concerns about the > "Ambivalent dynamic casting from Any” section. > > 1) When you

Re: [swift-evolution] [Review] SE-0116: Import Objective-C id as Swift Any type

Hey Joe, I’m +1 on the overall direction, but I have some questions/concerns about the "Ambivalent dynamic casting from Any” section. 1) When you suggest that `x as String` succeeds but `x as NSString` fails, I assume this would only be true *after* SE-0083, since otherwise we’d be violating

Re: [swift-evolution] [Review] SE-0116: Import Objective-C id as Swift Any type

>* What is your evaluation of the proposal? +1. I find this to be a solid, well reasoned proposal. I enjoyed seeing such a detailed Motivation and am looking forward to discussing the Related Proposals and Future Directions mentioned in this one. >* Is the problem being addressed

Re: [swift-evolution] [Review] SE-0116: Import Objective-C id as Swift Any type

> > What is your evaluation of the proposal? > +1 Is the problem being addressed significant enough to warrant a change to > Swift? > Yes. Passing value types to Objective-C APIs taking AnyObject requires creating wrapper classes that store the value types. This change would eliminate that

Re: [swift-evolution] [Review] SE-0116: Import Objective-C id as Swift Any type

> On Jul 5, 2016, at 6:37 PM, Joe Groff wrote: > >> >> On Jul 5, 2016, at 9:06 AM, Charlie Monroe via swift-evolution >> wrote: >> >> +1, but I'm not a big fan of the proposed Optional -> NSNull bridging which >> can cause various hard-to-debug

Re: [swift-evolution] [Review] SE-0116: Import Objective-C id as Swift Any type

> On Jul 5, 2016, at 9:06 AM, Charlie Monroe via swift-evolution > wrote: > > +1, but I'm not a big fan of the proposed Optional -> NSNull bridging which > can cause various hard-to-debug issues with errors "NSNull doesn't respond to > a selector -foo". I'm not

Re: [swift-evolution] [Review] SE-0116: Import Objective-C id as Swift Any type

+1, but I'm not a big fan of the proposed Optional -> NSNull bridging which can cause various hard-to-debug issues with errors "NSNull doesn't respond to a selector -foo". Most APIs that take "id" as an argument usually specify several types that the API accepts (e.g. arrays and dictionaries),

[swift-evolution] [Review] SE-0116: Import Objective-C id as Swift Any type

Hello Swift community, The review of "SE-0116: Import Objective-C id as Swift Any type" begins now and runs through July 11. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md Reviews are an important part of the Swift