Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

2016-07-02 Thread Kevin Lundberg via swift-evolution
+1, as long as the weird dynamic @objc method lookup behavior on AnyObject isn't also carried over to Any as part of this proposal. This behavior is a source of frustration for me as it reduces how much I can reason about code i work with when it creeps in unknowingly, and I don't even like

Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

2016-07-02 Thread Chris Lattner via swift-evolution
> On Jul 2, 2016, at 1:20 AM, Goffredo Marocchi wrote: > > Hey Chris, > > Do you have plans to allow people to update Swift outside Xcode 8 point > updates and still be able to submit to the App Store and benefit from the > IDE's features? This could allow bug fixes to be

Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

2016-07-02 Thread Shawn Erickson via swift-evolution
It does look like a huge benefit for many many current swift users. Thanks to the whole team trying to make this happen in Swift 3. On Fri, Jul 1, 2016 at 10:21 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jul 1, 2016, at 9:11 PM, David Waite via

Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

2016-07-02 Thread Goffredo Marocchi via swift-evolution
Hey Chris, Do you have plans to allow people to update Swift outside Xcode 8 point updates and still be able to submit to the App Store and benefit from the IDE's features? This could allow bug fixes to be delivered on a swifter way and take advantage of the fact that iOS is not including the

Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

2016-07-01 Thread Chris Lattner via swift-evolution
> On Jul 1, 2016, at 9:11 PM, David Waite via swift-evolution > wrote: > > +1! > > To me, it feels like the ambivalent dynamic casting is a temporary > complexity, and that at some point in the future the need to expose legacy > reference types like NSString

Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

2016-07-01 Thread David Waite via swift-evolution
+1! To me, it feels like the ambivalent dynamic casting is a temporary complexity, and that at some point in the future the need to expose legacy reference types like NSString outside swift-supplied or user-created bridging code will disappear completely. This also will get rid of some of the

Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

2016-07-01 Thread Matthew Johnson via swift-evolution
I'm really happy to see this. It cleans things up and enables some really important things such as more idiomatic bridging (NSNumber to native numeric types is amazing!). The ideas mentioned will really help to make Cocoa feel as Swifty as possible. Sent from my iPad > On Jul 1, 2016, at

Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

2016-07-01 Thread T.J. Usiyan via swift-evolution
+1 from me I think that it makes sense since there exists now a possibility for Obj-C types to come in as types with value semantics. TJ On Fri, Jul 1, 2016 at 7:37 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > Hi everyone. After implementing SE-0072, disabling the