Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 22, 2017, at 7:50 AM, Michel Fortin via swift-evolution > wrote: > >> * What is your evaluation of the proposal? > > Good. I'll certainly appreciate the added clarity of knowing which methods > are exposed to Objective-C. > > Currently, Swift-only apps are bloated by unnecessary Obj

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 29, 2017, at 3:00 PM, Douglas Gregor via swift-evolution > wrote: > > > * @implicitobjc added to a class implicitly makes members of that class *and > all of its subclasses* @objc if they can be exposed to Objective-C > * @implicitobjc added to a class extension makes members of that

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 23, 2017, at 2:06 AM, Slava Pestov via swift-evolution > wrote: > > Here’s an idea for working around the problem of the lack of static knowledge > during migration. Probably it’s kind of tacky and won’t get much traction in > it’s current form, but it might start some useful discuss

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 25, 2017, at 3:46 PM, Brent Royal-Gordon > wrote: > >> On Mar 24, 2017, at 10:09 AM, Douglas Gregor wrote: >> >>> I'm actually not worried about methods so much as properties. KVC is >>> completely untyped on the Objective-C side, and there are several different >>> mechanisms ther

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

>> 1) New projects that are generally pure Swift or include some ObjC files as >> a bridge for interaction with C++ or some other stuff Swift can't currently >> do. In such case, the NSObject inheritence is usually due to the >> NSObjectProtocol requirement defined by most delegates in Cocoa (T

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 26, 2017, at 8:23 PM, Charlie Monroe wrote: > >> >> On Mar 25, 2017, at 11:46 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> On Mar 24, 2017, at 10:09 AM, Douglas Gregor wrote: >>> Plus, inheritance from an Objective-C class is often incidental: you do it >>> because

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

Hey all, Separate from other feedback, we’ve noticed another minor wrinkle: XCTest uses the Objective-C runtime to discover tests in XCTestCase subclasses. While in the long term there is probably a better discovery method that works cross-platform, a more near-term solution would continue to i

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

Sorry if this is too long, but this proposal would greatly impact developers such as myself. > * What is your evaluation of the proposal? Strongly against it. I currently work in an iOS project with around 15 developers where the main target (not counting extensions or frameworks) has +1600 ObjC

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 25, 2017, at 11:46 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 24, 2017, at 10:09 AM, Douglas Gregor wrote: >> >>> I'm actually not worried about methods so much as properties. KVC is >>> completely untyped on the Objective-C side, and there are several different

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 24, 2017, at 10:09 AM, Douglas Gregor wrote: > >> I'm actually not worried about methods so much as properties. KVC is >> completely untyped on the Objective-C side, and there are several different >> mechanisms there which use KVC with poorly validated external strings, like >> bindi

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> Le 24 mars 2017 à 09:10, Charlie Monroe a écrit : > >> >> On Mar 24, 2017, at 8:20 AM, Jean-Daniel via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> Le 23 mars 2017 à 19:09, Douglas Gregor via swift-evolution >>> mailto:swift-evolution@swift.org>> a écrit : >>>

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 24, 2017, at 12:09 PM, Douglas Gregor via swift-evolution > wrote: >> >> I'm actually not worried about methods so much as properties. KVC is >> completely untyped on the Objective-C side, and there are several different >> mechanisms there which use KVC with poorly validated external

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 22, 2017, at 10:55 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution >> wrote: >> >> * What is your evaluation of the proposal? > > I'm going to have to come down on the "no" side on this one. > > I'm actually

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 24, 2017, at 8:20 AM, Jean-Daniel via swift-evolution > wrote: > >> >> Le 23 mars 2017 à 19:09, Douglas Gregor via swift-evolution >> mailto:swift-evolution@swift.org>> a écrit : >> >>> >>> On Mar 23, 2017, at 9:03 AM, Charlie Monroe >> > wrote: >>

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> Le 23 mars 2017 à 19:09, Douglas Gregor via swift-evolution > a écrit : > >> >> On Mar 23, 2017, at 9:03 AM, Charlie Monroe > > wrote: >> >>> >>> On Mar 23, 2017, at 9:44 AM, Slava Pestov >> > wrote: >>> On Mar 22, 201

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

We could spell the new attribute @objcMembers or something like that. Slava > On Mar 23, 2017, at 10:03 AM, Jordan Rose wrote: > > What happens for people using @objc to choose the class's runtime name? It > seems unfortunate to conflate that with changed inference. > > Jordan > > >> On Mar

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 23, 2017, at 1:46 AM, Slava Pestov via swift-evolution > wrote: > > >> On Mar 22, 2017, at 5:51 PM, Jordan Rose via swift-evolution >> wrote: >> >> [Proposal: >> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md] >> >> I'm definitely in favor o

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 23, 2017, at 9:03 AM, Charlie Monroe wrote: > >> >> On Mar 23, 2017, at 9:44 AM, Slava Pestov > > wrote: >> >>> >>> On Mar 22, 2017, at 10:34 PM, Charlie Monroe via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On Mar 23, 201

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 23, 2017, at 01:46, Slava Pestov wrote: > > >> On Mar 22, 2017, at 5:51 PM, Jordan Rose via swift-evolution >> wrote: >> >> [Proposal: >> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md] >> >> I'm definitely in favor of this. Apart from the va

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

What happens for people using @objc to choose the class's runtime name? It seems unfortunate to conflate that with changed inference. Jordan > On Mar 23, 2017, at 02:11, Slava Pestov via swift-evolution > wrote: > > A further benefit of this scheme is that it makes the behavior of @objc on

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 23, 2017, at 9:44 AM, Slava Pestov wrote: > >> >> On Mar 22, 2017, at 10:34 PM, Charlie Monroe via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Mar 23, 2017, at 12:02 AM, Douglas Gregor via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote:

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

A further benefit of this scheme is that it makes the behavior of @objc on class members consistent between NSObject-derived and Swift-native classes. Right now, it is legal to apply @objc to a _member_ of a Swift-native class; this is what allows Swift-native classes to model @objc protocols an

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

Here’s an idea for working around the problem of the lack of static knowledge during migration. Probably it’s kind of tacky and won’t get much traction in it’s current form, but it might start some useful discussion at least. Right now, @objc when applied to a _class_ is completely useless; if a

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 22, 2017, at 5:51 PM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md] > > I'm definitely in favor of this. Apart from the various motivations discussed > in the proposal, this also allow

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 22, 2017, at 10:34 PM, Charlie Monroe via swift-evolution > wrote: > >> >> On Mar 23, 2017, at 12:02 AM, Douglas Gregor via swift-evolution >> wrote: >> >> >>> On Mar 22, 2017, at 3:22 PM, Haravikk via swift-evolution >>> wrote: >>> >>> On 22 Mar 2017, at 06:03, Chris Lat

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 22, 2017, at 10:55 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution >> wrote: >> >> * What is your evaluation of the proposal? > > I'm going to have to come down on the "no" side on this one. > > I'm actually

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution > wrote: > > * What is your evaluation of the proposal? I'm going to have to come down on the "no" side on this one. I'm actually not worried about methods so much as properties. KVC is completely untyped on the Objective-C sid

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 23, 2017, at 12:02 AM, Douglas Gregor via swift-evolution > wrote: > > >> On Mar 22, 2017, at 3:22 PM, Haravikk via swift-evolution >> wrote: >> >> >>> On 22 Mar 2017, at 06:03, Chris Lattner via swift-evolution >>> wrote: >>> * What is your evaluation of the proposal? >> >> In

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> > * What is your evaluation of the proposal? > +1 in intent and -1 in detail. I think reducing the amount of magic helps make swift more powerful and easier to understand. This will force developers to add a few more `@objc` tokens, but the consistency will help in the long run. The last sectio

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md] I'm definitely in favor of this. Apart from the various motivations discussed in the proposal, this also allows some changes that could improve incremental builds: the generated header ("MyApp-Swif

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 22, 2017, at 3:22 PM, Haravikk via swift-evolution > wrote: > > >> On 22 Mar 2017, at 06:03, Chris Lattner via swift-evolution >> wrote: >> * What is your evaluation of the proposal? > > In favour. > > Like others I can foresee there being a bit of pain for some developers, but >

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On 22 Mar 2017, at 06:03, Chris Lattner via swift-evolution > wrote: > * What is your evaluation of the proposal? In favour. Like others I can foresee there being a bit of pain for some developers, but I think it's worth it to be more explicit about what's going on, and to clean up a featu

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

* What is your evaluation of the proposal? In theory, it seems like a great idea, but I fear that it will be one of those small changes that have disastrous effects on migrating code to Swift 4. There will likely be a ton of confusing errors and warnings that amount to "just add @objc to everything

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 22, 2017, at 7:50 AM, Michel Fortin via swift-evolution > wrote: > >> * What is your evaluation of the proposal? > > Good. I'll certainly appreciate the added clarity of knowing which methods > are exposed to Objective-C. > > Currently, Swift-only apps are bloated by unnecessary Obj

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> * What is your evaluation of the proposal? +1. This clarifies the interaction between Swift and Objective-C and reduces the magic that exists for bridging. It’s one more step on the road of Swift relying less on the Objective-C runtime - decoupling the semantics of `dynamic` from `@objc` i

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> * What is your evaluation of the proposal? Good. I'll certainly appreciate the added clarity of knowing which methods are exposed to Objective-C. Currently, Swift-only apps are bloated by unnecessary Objective-C thunks. The motivation section says that this will reduce the reduce the binary s

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

+1 > * What is your evaluation of the proposal? Seems to remove magic, which is something I can support, even if it means refactoring existing code. > * Is the problem being addressed significant enough to warrant a change to > Swift? Neutral > * Does this proposal fit well with the feel and

[swift-evolution] [Review] SE-0160: Limiting @objc inference

Hello Swift community, The review of "SE-0160: Limiting @objc inference" begins now and runs through March 28. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md Reviews are an important part of the Swift evolution pro