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

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

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

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

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

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,

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

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

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

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 >> > wrote: >> >>> >>> Le 23 mars 2017 à 19:09, Douglas Gregor via swift-evolution

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

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

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 >> > a écrit : >> >>> >>> On Mar 23, 2017, at 9:03 AM, Charlie

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

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

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: >>

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

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

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

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 >> > wrote: >> >>> >>> On Mar 23, 2017, at 12:02 AM, Douglas Gregor via swift-evolution

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

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

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

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

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

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

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

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

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

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

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

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

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

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`

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

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

[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