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

[Douglas Gregor via swift-evolution]

> 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 Objective-C thunks. The 
> motivation section says that this will reduce the reduce the binary sizes, 
> which is good, but should we expect not emitting those thunks will also 
> reduce by a bit the compilation times? Perhaps not by much, but I do think it 
> will.
> 
> I'm already littering some projects with plenty of `@nonobjc` annotations 
> because I don't need those thunks. This proposal would allow me to make this 
> cleaner. Perhaps the migrator should remove the `@nonobjc` attributes when 
> they become unnecessary. Actually, would the changes in this proposal make 
> the `@nonobjc` attribute irrelevant?
> 
> I'm a bit worried about the migration though.
> 
> I think it would be reasonable for the migrator to have two settings. A 
> conservative one that adds `@objc ` to all currently implicit `@objc` 
> declarations, to be used when you need to be absolutely certain everything 
> still works. Pruning of extra `@objc` would have to be done manually later, 
> if desired. And the default one that only adds `@objc` when the migrator sees 
> it as necessary.


FWIW, I’ve updated the proposal with a much more extensive discussion of the 
migration story. It incorporates “conservative” and “minimal” approaches, and 
describes how to do the “minimal” approach well. (It’s backed by a prototype 
implementation as well; see the Implementation link at the top”)

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Hooman Mehr via swift-evolution]

> 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 class 
> extension @objc if they can be exposed to Objective-C
> 
> This is a more elegant way to handle the XCTestCase issue—we can mark 
> XCTestCase as @implicitobjc through some Clang-side attribute or API note—and 
> makes it easy for class hierarchies that rely heavily on the Objective-C 
> runtime to continue to get @objc inference.

+1___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Douglas Gregor via swift-evolution]

> 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 discussion at least.
> 
> Right now, @objc when applied to a _class_ is completely useless; if a class 
> ultimately inherits from NSObject, it is always implicitly @objc, and 
> applying @objc to a class not rooted in NSObject is always an error. (I think 
> at some point in the past we allowed @objc classes that _don’t_ inherit from 
> NSObject, but I don’t know if that even made it into any released version of 
> Swift, so it’s totally vestigial at this point.) We can keep this behavior in 
> Swift 3 mode, but in Swift 4 mode, change things so that @objc applied to a 
> class enables @objc inference for the members of the class, and the absence 
> of @objc enables the new, more limited inference behavior outlined in this 
> proposal.
> 
> Then the migration story can just be “slap @objc on every NSObject-derived 
> class and you’re good”. Existing mixed source bases, KVC, and so on would 
> just work. We could also say that in Swift 4 mode, @objc on an 
> NSObject-derived class produces a warning asking the developer to consider 
> making individual members @objc as necessary instead. This would allow a 
> Swift 4 migration to proceed in two phases — first fix any fallout from 
> SE-0110 or new string stuff or whatever, and get a working app that builds 
> and runs in Swift 4 mode, albeit with some warnings. Then they can deal with 
> marking individual class members as @objc later. We could still have the 
> option of making it an error to apply @objc to an entire class in a future 
> release of Swift, if we decide it is beneficial to do so.

I don’t think we should repurpose @objc to mean “infer @objc if possible”, but 
we could add a new attribute—you’d mentioned @objcMembers somewhere before, 
I’ll refer to it as @implicitobjc” here—that one could added to classes or 
extensions. The semantics could be:

* @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 class 
extension @objc if they can be exposed to Objective-C

This is a more elegant way to handle the XCTestCase issue—we can mark 
XCTestCase as @implicitobjc through some Clang-side attribute or API note—and 
makes it easy for class hierarchies that rely heavily on the Objective-C 
runtime to continue to get @objc inference.

- Doug

> 
> Based on feedback, the all-or-nothing nature of the Swift 2->3 migration was 
> rather painful — mixing and matching 3 and 4 modules will definitely help us 
> do better the next time around, and allowing a complex change such as this 
> one to be done piecemeal could be a further step in the right direction.
> 
> Slava
> 
>> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 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 process. All reviews 
>> should be sent to the swift-evolution mailing list at:
>> 
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. 
>> 
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>> * What is your evaluation of the proposal?
>> * Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> * Does this proposal fit well with the feel and direction of Swift?
>> * If you have you used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>> * How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study? 
>> 
>> More information about the Swift evolution process is available at:
>>  https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> Thanks!
>> 
>> -Chris Lattner
>> Review Manager
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 

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

[Douglas Gregor via swift-evolution]

> 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 there which use KVC with poorly validated external strings, like 
>>> bindings, sort descriptors, and predicates. Tons of migration errors are 
>>> going to escape into production if we do this,
>> 
>> We can avoid these by migrating conservatively (have the migrator add @objc 
>> everywhere it’s inferred in Swift 3).
> 
> We can do that, but personally, I really hate these kinds of conservative 
> migrations. It might be unavoidable, though.
> 
>>> Have you considered a deprecation cycle (for instance, having Swift 4 
>>> thunks log a warning that they're going away in Swift 5)?
>> 
>> I think Swift 3 -> Swift 4 is the deprecation cycle, no?
> 
> But there was no indication during Swift 3 that this feature was going away. 
> As I understand it, a deprecation cycle introduces advanced warning of a 
> change so you have time to prepare for it; that's not available here.

The deprecation cycle is however long Swift 3 compatibility mode is around: 
Swift 3 compatibility mode can start warning about uses of the deprecated @objc 
inference—both in the compiler proper and at runtime via logging.

> 
> My concern is that, because the tools are not really aware of KVC, we can't 
> count on the compiler to lead developers to missing `@objc` properties. Folks 
> are only going to find those mistakes through testing, and they're inevitably 
> going to miss a few spots. So some poor schmuck is going to migrate their 
> code to Swift 4 without realizing this is an issue at all, accidentally miss 
> a few spots in their testing, ship it, and have to deal with weird crashes 
> out of nowhere. They're going to say, "My code worked just fine before. Swift 
> 4 broke it!" And they won't be wrong.
> 
> I'd be more comfortable with a version-long deprecation cycle that gave 
> developers plenty of time to notice these bugs. Failing that, I'd at least 
> like to see them get backtraces containing a symbol name like 
> `YouCantInvokeASwiftMemberThroughTheObjectiveCRuntimeUnlessItsMarkedWithAtObjc`
>  so the nature of the problem and its solution will be more obvious. 
> (Preferably, this function would log the instance and selector, so if people 
> got both the logs and the backtrace, the diagnosis would be as simple as we 
> can make it.)

We can do logs with a backtrace. This is fantastic suggestion also made earlier.

> (Actually, I wonder if we could install a `-doesNotRecognizeSelector:` 
> override in Swift classes which looked for a matching member in the Swift 
> runtime metadata and, if it found one, called the `YouCantInvoke…` function? 
> That would be lower overhead than generating stubs at compile time, and the 
> slowness of searching the runtime metadata wouldn't matter much since it was 
> going to crash anyway. I'm not sure if it might remove useful information 
> from the backtrace, though. Maybe in Swift 5, when these bugs will be more 
> rare. Or maybe in `SwiftObject`.)

The Objective-C thunks are nontrivial code patterns that we won’t be able to 
generate at runtime without a ton of infrastructure, so we’re stuck with 
statically generating the stubs. Also, we don’t have Swift runtime metadata for 
methods now.

> 
>> Plus, inheritance from an Objective-C class is often incidental: you do it 
>> because you need an NSObjectProtocol conformance, or something else expects 
>> NSObject. I haven’t heard of developers inheriting from NSObject solely to 
>> get @objc inference for their members.
> 
> You do it because you need a particular object to interact with Objective-C. 
> In that circumstance, I don't think the compiler is wrong to assume that you 
> want to expose as many members as possible to Objective-C.

You don’t need it for a particular object to interact with Objective-C; you 
need it so that the class itself is visible to Objective-C source code. Or 
because something forced you to inherit from NSObject (e.g,, the 
NSObjectProtocol, which I mentioned in my reply to Charles).

> 
>>> you already have to specify `dynamic` to avoid optimizations;
>> 
>> Conceptually, ‘dynamic’ is orthogonal to ‘@objc’. In today’s implementation, 
>> we can only implement ‘dynamic’ via the Objective-C runtime, hence this 
>> proposal’s requirement to write both.
> 
> I understand that, but again, I think it's defensible for the compiler to 
> assume that, if you want dynamic behavior in a class where you've already 
> enabled Objective-C interop, you probably want that dynamic behavior to be 
> compatible with Objective-C.
> 
> I guess we just take different standpoints on Objective-C interop. My belief 
> is that, if you state an intention to have a type interoperate with 
> 

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

[Charlie Monroe via swift-evolution]

>> 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 (Touch). In 
>> such cases, you're usually expecting just the delegate methods to be exposed 
>> to the ObjC runtime.
> 
> The NSObjectProtocol requirement is something that isn’t technically even 
> necessary in Swift. Every Swift class already defines implementations for 
> anything in NSObjectProtocol; we could, in fact, completely erase 
> NSObjectProtocol (or just call it AnyObject) and it would reduce the reliance 
> of Swift programs on NSObject.

If that would work, I'm all for it.

>> 2) Projects with mixed Swift/ObjC code, where you usually really need to 
>> expose as many members to ObjC as possible. As you need to communicate with 
>> your objects from ObjC, you need to indeed have most declaractions as @objc.
> 
> I do wonder about the “most” here; it implies that “most” non-private APIs 
> that aren’t overrides and aren’t satisfying @objc protocol requirements are 
> used from Objective-C.

That of course depends on the project, but e.g. for POD objects that aren't 
tied to CoreData, it is most of their members. I probably formulated the 
sentence wrong - what I mean was "most *public*" members. AFAIK the @objc 
inference doesn't really apply to private members.

> 
>> As it is, however, just the public API and it's usually just a temporary 
>> fix, I'm personally fine with marking them as @objc. By "temporary fix" I 
>> mean that with the future ahead, the ObjC code will eventually get rewritten 
>> to Swift, so it's a fix as long as you need to expose the API to ObjC.
> 
> Even if that isn’t the future for that codebase, @objc documents the use of 
> an API across languages.
> 
>> All things considered, I do agree that it's a huge change that would come 
>> too quickly and would agree on deprecating this in Swift 4 and removing in 
>> Swift 5.
> 
> 
>> Please keep in mind that for a one-person team such as myself, testing of 
>> e.g. 5 apps thoroughly simply takes a lot of time and as the releases of 
>> Swift are usually (or have been historically) in line with releases of new 
>> OS versions, there's a lot of pressure during those months leading to these 
>> releases on developers and postponing this change while giving them the 
>> tools (deprecation messages, breakpoint symbols) would IMHO help a lot.
> 
> Brent mentioned this desire for a longer deprecation cycle; I’ll reply to his 
> message on the topic.
> 
>   - Doug
> 
> 
> 
>> 
>> 
>>> 
> you already have to specify `dynamic` to avoid optimizations;
 
 Conceptually, ‘dynamic’ is orthogonal to ‘@objc’. In today’s 
 implementation, we can only implement ‘dynamic’ via the Objective-C 
 runtime, hence this proposal’s requirement to write both.
>>> 
>>> I understand that, but again, I think it's defensible for the compiler to 
>>> assume that, if you want dynamic behavior in a class where you've already 
>>> enabled Objective-C interop, you probably want that dynamic behavior to be 
>>> compatible with Objective-C.
>>> 
>>> I guess we just take different standpoints on Objective-C interop. My 
>>> belief is that, if you state an intention to have a type interoperate with 
>>> Objective-C, Swift should try to expose as many of its members to 
>>> Objective-C as possible. I think you believe that Swift should expose as 
>>> *little* as possible to Objective-C.
>>> 
>>> Because of that difference, I actually think I'd be *more* likely to 
>>> support removing inference by requiring an explicit `@nonobjc` on members 
>>> of Objective-C-compatible classes which aren't compatible with Objective-C. 
>>> That is, writing:
>>> 
>>> class Foo: NSObject {
>>> var bar: Int?
>>> }
>>> 
>>> Is an error; you have to write:
>>> 
>>> class Foo: NSObject {
>>> @nonobjc var bar: Int?
>>> }
>>> 
>>> I don't really like that answer very much, but I like it more than I would 
>>> like requiring `@objc` if `bar` were a plain `Int`.
>>> 
> Would you like the request for bridging notarized and filed in triplicate?
>>> 
>>> (By the way, in reading this later, I realized this part might have sounded 
>>> a little too angry. I was trying to be funny. Nobody complained, but I'm 
>>> sorry if I missed the mark here.)
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Douglas Gregor via swift-evolution]

> 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 you need an NSObjectProtocol conformance, or something else expects 
>>> NSObject. I haven’t heard of developers inheriting from NSObject solely to 
>>> get @objc inference for their members.
>> 
>> You do it because you need a particular object to interact with Objective-C. 
>> In that circumstance, I don't think the compiler is wrong to assume that you 
>> want to expose as many members as possible to Objective-C.
> 
> In my experience, there are two types of projects nowadays (in regards to 
> Swift-ObjC interop):
> 
> 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 (Touch). In such cases, you're 
> usually expecting just the delegate methods to be exposed to the ObjC runtime.

The NSObjectProtocol requirement is something that isn’t technically even 
necessary in Swift. Every Swift class already defines implementations for 
anything in NSObjectProtocol; we could, in fact, completely erase 
NSObjectProtocol (or just call it AnyObject) and it would reduce the reliance 
of Swift programs on NSObject.

> 2) Projects with mixed Swift/ObjC code, where you usually really need to 
> expose as many members to ObjC as possible. As you need to communicate with 
> your objects from ObjC, you need to indeed have most declaractions as @objc.

I do wonder about the “most” here; it implies that “most” non-private APIs that 
aren’t overrides and aren’t satisfying @objc protocol requirements are used 
from Objective-C.

> As it is, however, just the public API and it's usually just a temporary fix, 
> I'm personally fine with marking them as @objc. By "temporary fix" I mean 
> that with the future ahead, the ObjC code will eventually get rewritten to 
> Swift, so it's a fix as long as you need to expose the API to ObjC.

Even if that isn’t the future for that codebase, @objc documents the use of an 
API across languages.

> All things considered, I do agree that it's a huge change that would come too 
> quickly and would agree on deprecating this in Swift 4 and removing in Swift 
> 5.


> Please keep in mind that for a one-person team such as myself, testing of 
> e.g. 5 apps thoroughly simply takes a lot of time and as the releases of 
> Swift are usually (or have been historically) in line with releases of new OS 
> versions, there's a lot of pressure during those months leading to these 
> releases on developers and postponing this change while giving them the tools 
> (deprecation messages, breakpoint symbols) would IMHO help a lot.

Brent mentioned this desire for a longer deprecation cycle; I’ll reply to his 
message on the topic.

- Doug



> 
> 
>> 
 you already have to specify `dynamic` to avoid optimizations;
>>> 
>>> Conceptually, ‘dynamic’ is orthogonal to ‘@objc’. In today’s 
>>> implementation, we can only implement ‘dynamic’ via the Objective-C 
>>> runtime, hence this proposal’s requirement to write both.
>> 
>> I understand that, but again, I think it's defensible for the compiler to 
>> assume that, if you want dynamic behavior in a class where you've already 
>> enabled Objective-C interop, you probably want that dynamic behavior to be 
>> compatible with Objective-C.
>> 
>> I guess we just take different standpoints on Objective-C interop. My belief 
>> is that, if you state an intention to have a type interoperate with 
>> Objective-C, Swift should try to expose as many of its members to 
>> Objective-C as possible. I think you believe that Swift should expose as 
>> *little* as possible to Objective-C.
>> 
>> Because of that difference, I actually think I'd be *more* likely to support 
>> removing inference by requiring an explicit `@nonobjc` on members of 
>> Objective-C-compatible classes which aren't compatible with Objective-C. 
>> That is, writing:
>> 
>>  class Foo: NSObject {
>>  var bar: Int?
>>  }
>> 
>> Is an error; you have to write:
>> 
>>  class Foo: NSObject {
>>  @nonobjc var bar: Int?
>>  }
>> 
>> I don't really like that answer very much, but I like it more than I would 
>> like requiring `@objc` if `bar` were a plain `Int`.
>> 
 Would you like the request for bridging notarized and filed in triplicate?
>> 
>> (By the way, in reading this later, I realized this part might have sounded 
>> a little too angry. I was trying to be funny. Nobody complained, but I'm 
>> sorry if I missed the mark here.)
>> 
>> -- 
>> Brent 

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

[Víctor Pimentel Rodríguez via swift-evolution]

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
classes and +600 Swift files, and we are relying in the mix and match
for DI and testability reasons. Swift 3 migration was not easy, I tell
you ;)

In practice for us this change will mean that we will need prefix
every method and property with @objc for most of our NSObject
subclasses. And if we left any of them out the compiler will not warn
us and it could end up in production crashes and, worse, undefined
behaviour. While we don't want to add such @objc annotation, we surely
don't want those crashes.

> * Is the problem being addressed significant enough to warrant a change to 
> Swift?

My understanding is that the main problem is: "[...] Swift's rules for
inference of @objc are fairly baroque, and it is often unclear to
users when @objc will be inferred.".

Yes, that problem is significant enough and in real world apps that
live in the ObjC runtime we are seeing that this slows down a bit the
development and crashes are likely to end up in production. We are
careful enough so that not we don't have so many crashes, but in
development we have many wtf moments where we revisit why our code
isn't working as expected. This is very difficult to explain to
newcomers.

But I'm just not seeing how this proposal would fix this problem, if
any, it would make it worse and introduce lots of more bugs.

In fact the proposal states that some of the detected problems "are
out-of-scope". I'm very concerned by that, I see that the proposal has
been carefully thought but that avoiding bugs/crashes in shipping apps
is not a top priority.

This post kind of summarizes the current state of method dispatch within Swift:

https://www.raizlabs.com/dev/2016/12/swift-method-dispatch/

If I were to create an updated table with the proposed changes, would
that table be more complicated or less complicated? From my point of
view, it would complicate things even more.

So for me the important thing to ask would be: How do we want NSObject
subclasses to look like so that they are safer, faster and more
expressive than now?

I understand that the Core team may not be aligned with this view
since you don't want to compromise speed in such objects, even though
for shipping apps the speed gained at this level is much less
appreciated that the safety. But for me a NSObject subclass should
work as close as possible as if it was in ObjC. So I agree with the
Brian King post in that NSObject subclasses should always be dynamic.
In fact:

- If you inherit from NSObject, I would expose every method/property
to the ObjC runtime.
- If you inherit from NSObject, any property/method that cannot be
exposed to the ObjC runtime should have a @nonobjc annotation. The
compiler could easily enforce this.
- I would remove the dynamic keyword, since that is not a pure Swift
construct (not forever, but at least until it becomes a pure Swift
construct).
- I would remove the need for @objc except in the case of a name
refinement and protocol declaration. This includes optional methods in
@objc protocols.
- (I'm less sure about this) Private methods in NSObject subclasses
written in Swift should act as ObjC non-visible methods, they should
be dynamic but they should not appear in the bridging header.

These changes do not affect pure Swift classes or structs, so the fact
that right now Cocoa and other frameworks force you to use NSObject
subclasses in specific situations do not prevent you from using joyful
pure-Swift collaborators. Since it will make everything much more
predictable, this change will probably bump the use of pure Swift
constructs, which will make those pieces of code much more portable
than semi-NSObject classes. Of course this is completely out of scope
for this review, but it shows that there is another way of making
things simpler for every developer that now needs to write NSObject
subclasses.

In the future and in my particular case, I'm dreaming of Apple
frameworks that do not rely in the ObjC runtime, and of Swift
improvements to introspection and other dynamic features. In that
dream, your classes should not inherit from NSObject if you don't
want, and any of the changes that the community makes to @objc
inference will not apply.

> * Does this proposal fit well with the feel and direction of Swift?

As stated in https://swift.org/about/, the main goals of Swift are:

1. Safety, to the end that "developer mistakes should be caught before
software is in production".
2. Fastness, to the end that "Swift is intended as a replacement for
C-based languages (C, C++, and Objective-C). As such, Swift must be
comparable to those languages in performance for most tasks.
Performance must also be predictable and consistent [...]"
3. Expressiveness, 

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

[Charlie Monroe via swift-evolution]

> 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 
>>> mechanisms there which use KVC with poorly validated external strings, like 
>>> bindings, sort descriptors, and predicates. Tons of migration errors are 
>>> going to escape into production if we do this,
>> 
>> We can avoid these by migrating conservatively (have the migrator add @objc 
>> everywhere it’s inferred in Swift 3).
> 
> We can do that, but personally, I really hate these kinds of conservative 
> migrations. It might be unavoidable, though.
> 
>>> Have you considered a deprecation cycle (for instance, having Swift 4 
>>> thunks log a warning that they're going away in Swift 5)?
>> 
>> I think Swift 3 -> Swift 4 is the deprecation cycle, no?
> 
> But there was no indication during Swift 3 that this feature was going away. 
> As I understand it, a deprecation cycle introduces advanced warning of a 
> change so you have time to prepare for it; that's not available here.
> 
> My concern is that, because the tools are not really aware of KVC, we can't 
> count on the compiler to lead developers to missing `@objc` properties. Folks 
> are only going to find those mistakes through testing, and they're inevitably 
> going to miss a few spots. So some poor schmuck is going to migrate their 
> code to Swift 4 without realizing this is an issue at all, accidentally miss 
> a few spots in their testing, ship it, and have to deal with weird crashes 
> out of nowhere. They're going to say, "My code worked just fine before. Swift 
> 4 broke it!" And they won't be wrong.
> 
> I'd be more comfortable with a version-long deprecation cycle that gave 
> developers plenty of time to notice these bugs. Failing that, I'd at least 
> like to see them get backtraces containing a symbol name like 
> `YouCantInvokeASwiftMemberThroughTheObjectiveCRuntimeUnlessItsMarkedWithAtObjc`
>  so the nature of the problem and its solution will be more obvious. 
> (Preferably, this function would log the instance and selector, so if people 
> got both the logs and the backtrace, the diagnosis would be as simple as we 
> can make it.)
> 
> (Actually, I wonder if we could install a `-doesNotRecognizeSelector:` 
> override in Swift classes which looked for a matching member in the Swift 
> runtime metadata and, if it found one, called the `YouCantInvoke…` function? 
> That would be lower overhead than generating stubs at compile time, and the 
> slowness of searching the runtime metadata wouldn't matter much since it was 
> going to crash anyway. I'm not sure if it might remove useful information 
> from the backtrace, though. Maybe in Swift 5, when these bugs will be more 
> rare. Or maybe in `SwiftObject`.)
> 
>> Plus, inheritance from an Objective-C class is often incidental: you do it 
>> because you need an NSObjectProtocol conformance, or something else expects 
>> NSObject. I haven’t heard of developers inheriting from NSObject solely to 
>> get @objc inference for their members.
> 
> You do it because you need a particular object to interact with Objective-C. 
> In that circumstance, I don't think the compiler is wrong to assume that you 
> want to expose as many members as possible to Objective-C.

In my experience, there are two types of projects nowadays (in regards to 
Swift-ObjC interop):

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 (Touch). In such cases, you're 
usually expecting just the delegate methods to be exposed to the ObjC runtime.

2) Projects with mixed Swift/ObjC code, where you usually really need to expose 
as many members to ObjC as possible. As you need to communicate with your 
objects from ObjC, you need to indeed have most declaractions as @objc.

As it is, however, just the public API and it's usually just a temporary fix, 
I'm personally fine with marking them as @objc. By "temporary fix" I mean that 
with the future ahead, the ObjC code will eventually get rewritten to Swift, so 
it's a fix as long as you need to expose the API to ObjC.


All things considered, I do agree that it's a huge change that would come too 
quickly and would agree on deprecating this in Swift 4 and removing in Swift 5.

Please keep in mind that for a one-person team such as myself, testing of e.g. 
5 apps thoroughly simply takes a lot of time and as the releases of Swift are 
usually (or have been historically) in line with releases of new OS versions, 
there's a lot of pressure during those months leading to these releases on 
developers and 

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

[Brent Royal-Gordon via swift-evolution]

> 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 
>> bindings, sort descriptors, and predicates. Tons of migration errors are 
>> going to escape into production if we do this,
> 
> We can avoid these by migrating conservatively (have the migrator add @objc 
> everywhere it’s inferred in Swift 3).

We can do that, but personally, I really hate these kinds of conservative 
migrations. It might be unavoidable, though.

>> Have you considered a deprecation cycle (for instance, having Swift 4 thunks 
>> log a warning that they're going away in Swift 5)?
> 
> I think Swift 3 -> Swift 4 is the deprecation cycle, no?

But there was no indication during Swift 3 that this feature was going away. As 
I understand it, a deprecation cycle introduces advanced warning of a change so 
you have time to prepare for it; that's not available here.

My concern is that, because the tools are not really aware of KVC, we can't 
count on the compiler to lead developers to missing `@objc` properties. Folks 
are only going to find those mistakes through testing, and they're inevitably 
going to miss a few spots. So some poor schmuck is going to migrate their code 
to Swift 4 without realizing this is an issue at all, accidentally miss a few 
spots in their testing, ship it, and have to deal with weird crashes out of 
nowhere. They're going to say, "My code worked just fine before. Swift 4 broke 
it!" And they won't be wrong.

I'd be more comfortable with a version-long deprecation cycle that gave 
developers plenty of time to notice these bugs. Failing that, I'd at least like 
to see them get backtraces containing a symbol name like 
`YouCantInvokeASwiftMemberThroughTheObjectiveCRuntimeUnlessItsMarkedWithAtObjc` 
so the nature of the problem and its solution will be more obvious. 
(Preferably, this function would log the instance and selector, so if people 
got both the logs and the backtrace, the diagnosis would be as simple as we can 
make it.)

(Actually, I wonder if we could install a `-doesNotRecognizeSelector:` override 
in Swift classes which looked for a matching member in the Swift runtime 
metadata and, if it found one, called the `YouCantInvoke…` function? That would 
be lower overhead than generating stubs at compile time, and the slowness of 
searching the runtime metadata wouldn't matter much since it was going to crash 
anyway. I'm not sure if it might remove useful information from the backtrace, 
though. Maybe in Swift 5, when these bugs will be more rare. Or maybe in 
`SwiftObject`.)

> Plus, inheritance from an Objective-C class is often incidental: you do it 
> because you need an NSObjectProtocol conformance, or something else expects 
> NSObject. I haven’t heard of developers inheriting from NSObject solely to 
> get @objc inference for their members.

You do it because you need a particular object to interact with Objective-C. In 
that circumstance, I don't think the compiler is wrong to assume that you want 
to expose as many members as possible to Objective-C.

>> you already have to specify `dynamic` to avoid optimizations;
> 
> Conceptually, ‘dynamic’ is orthogonal to ‘@objc’. In today’s implementation, 
> we can only implement ‘dynamic’ via the Objective-C runtime, hence this 
> proposal’s requirement to write both.

I understand that, but again, I think it's defensible for the compiler to 
assume that, if you want dynamic behavior in a class where you've already 
enabled Objective-C interop, you probably want that dynamic behavior to be 
compatible with Objective-C.

I guess we just take different standpoints on Objective-C interop. My belief is 
that, if you state an intention to have a type interoperate with Objective-C, 
Swift should try to expose as many of its members to Objective-C as possible. I 
think you believe that Swift should expose as *little* as possible to 
Objective-C.

Because of that difference, I actually think I'd be *more* likely to support 
removing inference by requiring an explicit `@nonobjc` on members of 
Objective-C-compatible classes which aren't compatible with Objective-C. That 
is, writing:

class Foo: NSObject {
var bar: Int?
}

Is an error; you have to write:

class Foo: NSObject {
@nonobjc var bar: Int?
}

I don't really like that answer very much, but I like it more than I would like 
requiring `@objc` if `bar` were a plain `Int`.

>> Would you like the request for bridging notarized and filed in triplicate?

(By the way, in reading this later, I realized this part might have sounded a 
little too angry. I was trying to be funny. Nobody complained, but I'm sorry if 
I missed the mark here.)

-- 
Brent Royal-Gordon
Architechies

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

[Jean-Daniel via swift-evolution]

> 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 
>>> > 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, 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 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 feature that's just for supporting a 
 specific other language.
 
 My main concern is on whether things could be made a bit easier; 
 specifically I wonder whether we could introduce an option (to the 
 compiler?) to trigger warnings anywhere there is a possible missing 
 @objc attribute. Basically on any code that produces bridging headers 
 this would give a warning anywhere that @objc would have been inferred 
 in the past, but will no longer be. Of course this will generate a lot 
 of warnings, but it'll be an easier way for developers to go through 
 and make sure they didn't miss something. Xcode could offer this 
 automatically during migration, and the developer can turn it off when 
 they're done. Not perfect, but it may be a little extra help for those 
 most affected?
>>> 
>>> The source compatibility section of the proposal
>>> 
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md#source-compatibility
>>>  
>>> 
>>> 
>>> describes the use of NS_DEPRECATED in the generated header for Swift 3 
>>> compatibility mode to get warnings on uses of entities that are 
>>> implicitly @objc but will no longer be in Swift 4. Does that address 
>>> your concern?
>>> 
>>> I’ve also heard the idea of putting the same warnings into the 
>>> generated Objective-C thunks by NSLog’ing the same information as an 
>>> opt-in, pre-Swift-4-migration step to help catch the tricky cases where 
>>> an Objective-C entrypoint is getting called.
>> 
>> I would very much like that, mostly for catching all scenarios with 
>> bindings on the Mac.
>> 
>> Otherwise, I agree with the proposal, just am a bit concerned with some 
>> of my apps that heavily use bindings…
> 
> Perhaps a better solution than NSLog would be if the existing code 
> coverage support could be modified to instrument @objc thunks, but I 
> don’t know the details well enough to say if this would be practical to 
> implement in the Swift 4 time frame.
 
 What about a symbol for a breakpoint? Like Auto Layout and many other 
 frameworks (e.g. break on _NSErrorLog(), etc.) have…
>>> 
>>> That’s a great idea! We could have the implicit @objc thunks call into 
>>> _swift3ImplicitObjCEntrypoint (or similar).
>> 
>> What about using dtrace to reduce the performance cost of such feature ? 
>> This is exactly what is was design for. Being able to trace a program when 
>> needed without paying for it when not necessary.
> 
> Correct me, if I'm wrong, but there will be no performance cost. This entry 
> point would get called only from thunks that will go away in Swift 4 anyway 
> and only in debug mode (possibly?).
> 
> This way all @nonobjc calls within Swift are without the ObjC thunks (thus 
> the entrypoint is not called), all explicitly @objc thunks are free of this 
> entry point call and the only place this gets called is when your object gets 
> a call from Objective-C code (runtime) to a thunk that is @objc implicitly 
> and hence is going away in Swift 4 anyway and should be marked as @objc 
> explicitly.
> 
> This means:

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

[Charles Srstka via swift-evolution]

> 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 strings, like 
>> bindings, sort descriptors, and predicates. Tons of migration errors are 
>> going to escape into production if we do this,
> 
> We can avoid these by migrating conservatively (have the migrator add @objc 
> everywhere it’s inferred in Swift 3).
> 
>> and undetectable mistakes are going to continue on an ongoing basis. 
> 
> … but what you say above is definitely true: the error of omission of @objc 
> will cause breakage for these cases. 

This might be a temporary situation, though: is there any reason, especially 
given that there’s now a “compilation” process for .xib files, that the format 
couldn’t be updated to be able to connect to native Swift code? We’d need to 
add some native implementation of ‘dynamic’ and some equivalent to KVO, but 
those aren’t insurmountable obstacles for the future. If this eventually 
happens, the errors of omission will prove to be temporary. And in the 
meantime, code could probably even be added to the .xib compiler to warn when 
non-@objc things are referenced.

>> you already have to specify `dynamic` to avoid optimizations;
> 
> Conceptually, ‘dynamic’ is orthogonal to ‘@objc’. In today’s implementation, 
> we can only implement ‘dynamic’ via the Objective-C runtime, hence this 
> proposal’s requirement to write both.

The prospect of eventually having a Swift-native implementation of ‘dynamic’, 
thus enabling the above, is what pushes me over the fence to +1 on this 
proposal.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Douglas Gregor via swift-evolution]

> 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 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 
> bindings, sort descriptors, and predicates. Tons of migration errors are 
> going to escape into production if we do this,

We can avoid these by migrating conservatively (have the migrator add @objc 
everywhere it’s inferred in Swift 3).

> and undetectable mistakes are going to continue on an ongoing basis. 

… but what you say above is definitely true: the error of omission of @objc 
will cause breakage for these cases. 


> Have we explored alternate implementations? For instance, when the compiler 
> can statically determine all of the call sites for an `@objc` member, could 
> we emit *only* an implementation with the Objective-C calling convention and 
> call that directly from Swift?
> 
> Could members with binary-compatible signatures share a thunk? The 
> Objective-C calling convention includes a selector parameter, so you can 
> still determine the desired message.
> 
> Could we give implicit methods and properties a different, slower 
> implementation that leverages Objective-C's dynamic features? Imagine, for 
> instance, mapping in `imp_implementationWithBlock()`-style pages of 
> general-purpose thunks at runtime to reduce code size, then installing them 
> lazily with `+resolveClassMethod:`. (Maybe this could actually be made fast 
> enough, amortized over all calls, that we could get rid of the thunks 
> entirely—I don't know.)

(Slava talked through some of these)

> Have you evaluated applying different rules to methods and properties?

For me, I’d rather reject the proposal as a whole than further complicate the 
rules for @objc inference.

> Have you considered a deprecation cycle (for instance, having Swift 4 thunks 
> log a warning that they're going away in Swift 5)?

I think Swift 3 -> Swift 4 is the deprecation cycle, no?

> Or is the real motivation that, code size issues aside, you think these 
> members ought to be explicitly marked `@objc` for philosophical reasons?

That’s certainly *a* reason. The @objc inference rules are fairly complicated 
and even experienced developers can’t easily guess whether something will be 
exposed to Objective-C or not because (e.g.) minor changes in the 
parameter/result types of a method can affect it.

> If so, how many times do you want people to say so?

Once per API that’s exposed to Objective-C.

> You already have to explicitly inherit from an `@objc` base class;

You don’t *need* to inherit from an `@objc` base class to have an @objc member, 
but @objc inference ties together the notions of 

Plus, inheritance from an Objective-C class is often incidental: you do it 
because you need an NSObjectProtocol conformance, or something else expects 
NSObject. I haven’t heard of developers inheriting from NSObject solely to get 
@objc inference for their members.

> you already have to specify `dynamic` to avoid optimizations;

Conceptually, ‘dynamic’ is orthogonal to ‘@objc’. In today’s implementation, we 
can only implement ‘dynamic’ via the Objective-C runtime, hence this proposal’s 
requirement to write both.

> now you also have to mark individual members `@objc`? Would you like the 
> request for bridging notarized and filed in triplicate?

> I can understand the impulse to require it explicitly on `public` members, 
> but on the other hand, if you *do* accidentally publish a member as `@objc`, 
> what's the harm? Is there any non-breaking change you can make to a 
> `@nonobjc` method which wouldn't be legal on an `@objc` one?

There probably are; making an Int parameter of a final method Int? isn’t 
generally source-breaking, but means that you can no longer expose an @objc 
entrypoint. That said...

> Or can you just deprecate the `@objc` version and move on?

it’s easy to leave a deprecated @objc entrypoint in place if this happened to 
you, so I don’t think “accidentally made an @objc API that I wanted to be 
@nonobjc and now I have to support it going forward” is  strong argument in 
favor of this proposal.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

> 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 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 
> > 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 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 feature that's just for supporting a 
>>> specific other language.
>>> 
>>> My main concern is on whether things could be made a bit easier; 
>>> specifically I wonder whether we could introduce an option (to the 
>>> compiler?) to trigger warnings anywhere there is a possible missing 
>>> @objc attribute. Basically on any code that produces bridging headers 
>>> this would give a warning anywhere that @objc would have been inferred 
>>> in the past, but will no longer be. Of course this will generate a lot 
>>> of warnings, but it'll be an easier way for developers to go through 
>>> and make sure they didn't miss something. Xcode could offer this 
>>> automatically during migration, and the developer can turn it off when 
>>> they're done. Not perfect, but it may be a little extra help for those 
>>> most affected?
>> 
>> The source compatibility section of the proposal
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md#source-compatibility
>>  
>> 
>> 
>> describes the use of NS_DEPRECATED in the generated header for Swift 3 
>> compatibility mode to get warnings on uses of entities that are 
>> implicitly @objc but will no longer be in Swift 4. Does that address 
>> your concern?
>> 
>> I’ve also heard the idea of putting the same warnings into the generated 
>> Objective-C thunks by NSLog’ing the same information as an opt-in, 
>> pre-Swift-4-migration step to help catch the tricky cases where an 
>> Objective-C entrypoint is getting called.
> 
> I would very much like that, mostly for catching all scenarios with 
> bindings on the Mac.
> 
> Otherwise, I agree with the proposal, just am a bit concerned with some 
> of my apps that heavily use bindings…
 
 Perhaps a better solution than NSLog would be if the existing code 
 coverage support could be modified to instrument @objc thunks, but I don’t 
 know the details well enough to say if this would be practical to 
 implement in the Swift 4 time frame.
>>> 
>>> What about a symbol for a breakpoint? Like Auto Layout and many other 
>>> frameworks (e.g. break on _NSErrorLog(), etc.) have…
>> 
>> That’s a great idea! We could have the implicit @objc thunks call into 
>> _swift3ImplicitObjCEntrypoint (or similar).
> 
> What about using dtrace to reduce the performance cost of such feature ? This 
> is exactly what is was design for. Being able to trace a program when needed 
> without paying for it when not necessary.

Correct me, if I'm wrong, but there will be no performance cost. This entry 
point would get called only from thunks that will go away in Swift 4 anyway and 
only in debug mode (possibly?).

This way all @nonobjc calls within Swift are without the ObjC thunks (thus the 
entrypoint is not called), all explicitly @objc thunks are free of this entry 
point call and the only place this gets called is when your object gets a call 
from Objective-C code (runtime) to a thunk that is @objc implicitly and hence 
is going away in Swift 4 anyway and should be marked as @objc explicitly.

This means:

- 0 cost for production code
- 0 cost for Swift-to-Swift calls (@nonobjc)
- 0 cost for explicit @objc calls

While DTrace is nice, I don't see the benefit of it here as you'd need to run 
it through Instruments instead of just setting a 

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

[Jean-Daniel via swift-evolution]

> 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, 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 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 feature that's just for supporting a specific other 
>> language.
>> 
>> My main concern is on whether things could be made a bit easier; 
>> specifically I wonder whether we could introduce an option (to the 
>> compiler?) to trigger warnings anywhere there is a possible missing 
>> @objc attribute. Basically on any code that produces bridging headers 
>> this would give a warning anywhere that @objc would have been inferred 
>> in the past, but will no longer be. Of course this will generate a lot 
>> of warnings, but it'll be an easier way for developers to go through and 
>> make sure they didn't miss something. Xcode could offer this 
>> automatically during migration, and the developer can turn it off when 
>> they're done. Not perfect, but it may be a little extra help for those 
>> most affected?
> 
> The source compatibility section of the proposal
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md#source-compatibility
>  
> 
> 
> describes the use of NS_DEPRECATED in the generated header for Swift 3 
> compatibility mode to get warnings on uses of entities that are 
> implicitly @objc but will no longer be in Swift 4. Does that address your 
> concern?
> 
> I’ve also heard the idea of putting the same warnings into the generated 
> Objective-C thunks by NSLog’ing the same information as an opt-in, 
> pre-Swift-4-migration step to help catch the tricky cases where an 
> Objective-C entrypoint is getting called.
 
 I would very much like that, mostly for catching all scenarios with 
 bindings on the Mac.
 
 Otherwise, I agree with the proposal, just am a bit concerned with some of 
 my apps that heavily use bindings…
>>> 
>>> Perhaps a better solution than NSLog would be if the existing code coverage 
>>> support could be modified to instrument @objc thunks, but I don’t know the 
>>> details well enough to say if this would be practical to implement in the 
>>> Swift 4 time frame.
>> 
>> What about a symbol for a breakpoint? Like Auto Layout and many other 
>> frameworks (e.g. break on _NSErrorLog(), etc.) have…
> 
> That’s a great idea! We could have the implicit @objc thunks call into 
> _swift3ImplicitObjCEntrypoint (or similar).

What about using dtrace to reduce the performance cost of such feature ? This 
is exactly what is was design for. Being able to trace a program when needed 
without paying for it when not necessary.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

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 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 
>> 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 and so on. 
>> But of course we don’t ever implicitly infer @objc on members of 
>> Swift-native classes just based on the calling convention of a method.
>> 
>> So now we could say that members of non-@objc classes only infer @objc if 
>> necessary to fulfill an override or protocol requirement, independently of 
>> whether the class is NSObject-derived or not; and @objc can now be applied 
>> to an entire class, as long as its NSObject-derived, to get the implicit 
>> inference behavior on members.
>> 
>> Slava
>> 
>>> On Mar 23, 2017, at 2:06 AM, Slava Pestov  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 discussion at 
>>> least.
>>> 
>>> Right now, @objc when applied to a _class_ is completely useless; if a 
>>> class ultimately inherits from NSObject, it is always implicitly @objc, and 
>>> applying @objc to a class not rooted in NSObject is always an error. (I 
>>> think at some point in the past we allowed @objc classes that _don’t_ 
>>> inherit from NSObject, but I don’t know if that even made it into any 
>>> released version of Swift, so it’s totally vestigial at this point.) We can 
>>> keep this behavior in Swift 3 mode, but in Swift 4 mode, change things so 
>>> that @objc applied to a class enables @objc inference for the members of 
>>> the class, and the absence of @objc enables the new, more limited inference 
>>> behavior outlined in this proposal.
>>> 
>>> Then the migration story can just be “slap @objc on every NSObject-derived 
>>> class and you’re good”. Existing mixed source bases, KVC, and so on would 
>>> just work. We could also say that in Swift 4 mode, @objc on an 
>>> NSObject-derived class produces a warning asking the developer to consider 
>>> making individual members @objc as necessary instead. This would allow a 
>>> Swift 4 migration to proceed in two phases — first fix any fallout from 
>>> SE-0110 or new string stuff or whatever, and get a working app that builds 
>>> and runs in Swift 4 mode, albeit with some warnings. Then they can deal 
>>> with marking individual class members as @objc later. We could still have 
>>> the option of making it an error to apply @objc to an entire class in a 
>>> future release of Swift, if we decide it is beneficial to do so.
>>> 
>>> Based on feedback, the all-or-nothing nature of the Swift 2->3 migration 
>>> was rather painful — mixing and matching 3 and 4 modules will definitely 
>>> help us do better the next time around, and allowing a complex change such 
>>> as this one to be done piecemeal could be a further step in the right 
>>> direction.
>>> 
>>> Slava
>>> 
 On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution 
  wrote:
 
 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 process. All reviews 
 should be sent to the swift-evolution mailing list at:
 
https://lists.swift.org/mailman/listinfo/swift-evolution
 
 or, if you would like to keep your feedback private, directly to the 
 review manager. 
 
 
 What goes into a review?
 
 The goal of the review process is to improve the proposal under review 
 through constructive criticism and, eventually, determine the direction of 
 Swift. When writing your review, here are some questions you might want to 
 answer in your review:
 
 * What is your evaluation of the proposal?
 * Is the problem being addressed significant enough to warrant a change to 
 Swift?
 * Does this proposal fit well with the feel and direction of Swift?
 * If you have you used other languages or libraries with a similar 
 feature, how do you feel that this proposal compares to those?
 * How much effort did you put into your review? A glance, a quick reading, 
 or an 

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

[Jonathan Hull via swift-evolution]

> 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 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-Swift.h") wouldn't need to 
>> be regenerated nearly as often with fewer methods exposed to Objective-C. 
>> (There's some nuance here that I don't need to go into right now, and there 
>> are alternate solutions to that problem, but it's nice that the common case 
>> will just put fewer declarations into the header and therefore it would 
>> change less often.)
>> 
>> The migration aspect is a little scary. #selector's Objective-C equivalent 
>> is @selector, which is easy to search for, but #keyPath maps to plain old 
>> strings.
> 
> Are these strings usually literal strings that are passed in to some set of 
> mostly-known selector names, or do people pass them around or even construct 
> them dynamically?

I have cases where I read the strings in from a plist or json, and then use 
them to bind the model with the UI (which may have been auto generated).  For 
example, I have a file which defines a UI which should be dynamically 
generated, and then binds the generated interface to a facade which talks to a 
database (performing any conversions necessary to make the connections work).  
That way, I can add new types of things simply by adding a plist to my app 
(which is much easier and less error prone than hand coding each sub-UI)

I have been experimenting with doing this in a swift-ier way lately, with some 
success, but it is still much more complex and finicky than the ObjC way.

Thanks,
Jon
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Douglas Gregor via swift-evolution]

> 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 
>>> > 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 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 feature that's just for supporting a specific other 
> language.
> 
> My main concern is on whether things could be made a bit easier; 
> specifically I wonder whether we could introduce an option (to the 
> compiler?) to trigger warnings anywhere there is a possible missing @objc 
> attribute. Basically on any code that produces bridging headers this 
> would give a warning anywhere that @objc would have been inferred in the 
> past, but will no longer be. Of course this will generate a lot of 
> warnings, but it'll be an easier way for developers to go through and 
> make sure they didn't miss something. Xcode could offer this 
> automatically during migration, and the developer can turn it off when 
> they're done. Not perfect, but it may be a little extra help for those 
> most affected?
 
 The source compatibility section of the proposal
 

 https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md#source-compatibility
  
 
 
 describes the use of NS_DEPRECATED in the generated header for Swift 3 
 compatibility mode to get warnings on uses of entities that are implicitly 
 @objc but will no longer be in Swift 4. Does that address your concern?
 
 I’ve also heard the idea of putting the same warnings into the generated 
 Objective-C thunks by NSLog’ing the same information as an opt-in, 
 pre-Swift-4-migration step to help catch the tricky cases where an 
 Objective-C entrypoint is getting called.
>>> 
>>> I would very much like that, mostly for catching all scenarios with 
>>> bindings on the Mac.
>>> 
>>> Otherwise, I agree with the proposal, just am a bit concerned with some of 
>>> my apps that heavily use bindings…
>> 
>> Perhaps a better solution than NSLog would be if the existing code coverage 
>> support could be modified to instrument @objc thunks, but I don’t know the 
>> details well enough to say if this would be practical to implement in the 
>> Swift 4 time frame.
> 
> What about a symbol for a breakpoint? Like Auto Layout and many other 
> frameworks (e.g. break on _NSErrorLog(), etc.) have…

That’s a great idea! We could have the implicit @objc thunks call into 
_swift3ImplicitObjCEntrypoint (or similar).

- Doug


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jordan Rose via swift-evolution]

> 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 various motivations 
>> discussed in the proposal, this also allows some changes that could improve 
>> incremental builds: the generated header ("MyApp-Swift.h") wouldn't need to 
>> be regenerated nearly as often with fewer methods exposed to Objective-C. 
>> (There's some nuance here that I don't need to go into right now, and there 
>> are alternate solutions to that problem, but it's nice that the common case 
>> will just put fewer declarations into the header and therefore it would 
>> change less often.)
>> 
>> The migration aspect is a little scary. #selector's Objective-C equivalent 
>> is @selector, which is easy to search for, but #keyPath maps to plain old 
>> strings.
> 
> Are these strings usually literal strings that are passed in to some set of 
> mostly-known selector names, or do people pass them around or even construct 
> them dynamically?

Yeah, that's a saving factor. If someone made a list of all the 
KVC/KVO/bindings APIs and looked for uses in their project, they'd probably get 
most of them (with the minor complication of the argument usually being a key 
path and not just a single key).

Jordan

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jordan Rose via swift-evolution]

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 
> 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 and so on. 
> But of course we don’t ever implicitly infer @objc on members of Swift-native 
> classes just based on the calling convention of a method.
> 
> So now we could say that members of non-@objc classes only infer @objc if 
> necessary to fulfill an override or protocol requirement, independently of 
> whether the class is NSObject-derived or not; and @objc can now be applied to 
> an entire class, as long as its NSObject-derived, to get the implicit 
> inference behavior on members.
> 
> Slava
> 
>> On Mar 23, 2017, at 2:06 AM, Slava Pestov  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 discussion at 
>> least.
>> 
>> Right now, @objc when applied to a _class_ is completely useless; if a class 
>> ultimately inherits from NSObject, it is always implicitly @objc, and 
>> applying @objc to a class not rooted in NSObject is always an error. (I 
>> think at some point in the past we allowed @objc classes that _don’t_ 
>> inherit from NSObject, but I don’t know if that even made it into any 
>> released version of Swift, so it’s totally vestigial at this point.) We can 
>> keep this behavior in Swift 3 mode, but in Swift 4 mode, change things so 
>> that @objc applied to a class enables @objc inference for the members of the 
>> class, and the absence of @objc enables the new, more limited inference 
>> behavior outlined in this proposal.
>> 
>> Then the migration story can just be “slap @objc on every NSObject-derived 
>> class and you’re good”. Existing mixed source bases, KVC, and so on would 
>> just work. We could also say that in Swift 4 mode, @objc on an 
>> NSObject-derived class produces a warning asking the developer to consider 
>> making individual members @objc as necessary instead. This would allow a 
>> Swift 4 migration to proceed in two phases — first fix any fallout from 
>> SE-0110 or new string stuff or whatever, and get a working app that builds 
>> and runs in Swift 4 mode, albeit with some warnings. Then they can deal with 
>> marking individual class members as @objc later. We could still have the 
>> option of making it an error to apply @objc to an entire class in a future 
>> release of Swift, if we decide it is beneficial to do so.
>> 
>> Based on feedback, the all-or-nothing nature of the Swift 2->3 migration was 
>> rather painful — mixing and matching 3 and 4 modules will definitely help us 
>> do better the next time around, and allowing a complex change such as this 
>> one to be done piecemeal could be a further step in the right direction.
>> 
>> Slava
>> 
>>> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> 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 process. All reviews 
>>> should be sent to the swift-evolution mailing list at:
>>> 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager. 
>>> 
>>> 
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and, eventually, determine the direction of 
>>> Swift. When writing your review, here are some questions you might want to 
>>> answer in your review:
>>> 
>>> * What is your evaluation of the proposal?
>>> * Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>>> * Does this proposal fit well with the feel and direction of Swift?
>>> * If you have you used other languages or libraries with a similar feature, 
>>> how do you feel that this proposal compares to those?
>>> * How much effort did you put into your review? A glance, a quick reading, 
>>> or an in-depth study? 
>>> 
>>> More information about the Swift evolution process is available at:
>>> https://github.com/apple/swift-evolution/blob/master/process.md 
>>> 
>>> Thanks!
>>> 
>>> -Chris Lattner
>>> Review Manager
>>> 

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

[Charlie Monroe via swift-evolution]

> 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 
>>> > 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 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 feature that's just for supporting a specific other language.
 
 My main concern is on whether things could be made a bit easier; 
 specifically I wonder whether we could introduce an option (to the 
 compiler?) to trigger warnings anywhere there is a possible missing @objc 
 attribute. Basically on any code that produces bridging headers this would 
 give a warning anywhere that @objc would have been inferred in the past, 
 but will no longer be. Of course this will generate a lot of warnings, but 
 it'll be an easier way for developers to go through and make sure they 
 didn't miss something. Xcode could offer this automatically during 
 migration, and the developer can turn it off when they're done. Not 
 perfect, but it may be a little extra help for those most affected?
>>> 
>>> The source compatibility section of the proposal
>>> 
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md#source-compatibility
>>>  
>>> 
>>> 
>>> describes the use of NS_DEPRECATED in the generated header for Swift 3 
>>> compatibility mode to get warnings on uses of entities that are implicitly 
>>> @objc but will no longer be in Swift 4. Does that address your concern?
>>> 
>>> I’ve also heard the idea of putting the same warnings into the generated 
>>> Objective-C thunks by NSLog’ing the same information as an opt-in, 
>>> pre-Swift-4-migration step to help catch the tricky cases where an 
>>> Objective-C entrypoint is getting called.
>> 
>> I would very much like that, mostly for catching all scenarios with bindings 
>> on the Mac.
>> 
>> Otherwise, I agree with the proposal, just am a bit concerned with some of 
>> my apps that heavily use bindings…
> 
> Perhaps a better solution than NSLog would be if the existing code coverage 
> support could be modified to instrument @objc thunks, but I don’t know the 
> details well enough to say if this would be practical to implement in the 
> Swift 4 time frame.

What about a symbol for a breakpoint? Like Auto Layout and many other 
frameworks (e.g. break on _NSErrorLog(), etc.) have...




> 
> Slava
> 
>> 
>>> 
>>> - Doug
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

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 and so on. 
But of course we don’t ever implicitly infer @objc on members of Swift-native 
classes just based on the calling convention of a method.

So now we could say that members of non-@objc classes only infer @objc if 
necessary to fulfill an override or protocol requirement, independently of 
whether the class is NSObject-derived or not; and @objc can now be applied to 
an entire class, as long as its NSObject-derived, to get the implicit inference 
behavior on members.

Slava

> On Mar 23, 2017, at 2:06 AM, Slava Pestov  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 discussion at least.
> 
> Right now, @objc when applied to a _class_ is completely useless; if a class 
> ultimately inherits from NSObject, it is always implicitly @objc, and 
> applying @objc to a class not rooted in NSObject is always an error. (I think 
> at some point in the past we allowed @objc classes that _don’t_ inherit from 
> NSObject, but I don’t know if that even made it into any released version of 
> Swift, so it’s totally vestigial at this point.) We can keep this behavior in 
> Swift 3 mode, but in Swift 4 mode, change things so that @objc applied to a 
> class enables @objc inference for the members of the class, and the absence 
> of @objc enables the new, more limited inference behavior outlined in this 
> proposal.
> 
> Then the migration story can just be “slap @objc on every NSObject-derived 
> class and you’re good”. Existing mixed source bases, KVC, and so on would 
> just work. We could also say that in Swift 4 mode, @objc on an 
> NSObject-derived class produces a warning asking the developer to consider 
> making individual members @objc as necessary instead. This would allow a 
> Swift 4 migration to proceed in two phases — first fix any fallout from 
> SE-0110 or new string stuff or whatever, and get a working app that builds 
> and runs in Swift 4 mode, albeit with some warnings. Then they can deal with 
> marking individual class members as @objc later. We could still have the 
> option of making it an error to apply @objc to an entire class in a future 
> release of Swift, if we decide it is beneficial to do so.
> 
> Based on feedback, the all-or-nothing nature of the Swift 2->3 migration was 
> rather painful — mixing and matching 3 and 4 modules will definitely help us 
> do better the next time around, and allowing a complex change such as this 
> one to be done piecemeal could be a further step in the right direction.
> 
> Slava
> 
>> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 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 process. All reviews 
>> should be sent to the swift-evolution mailing list at:
>> 
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. 
>> 
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>> * What is your evaluation of the proposal?
>> * Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> * Does this proposal fit well with the feel and direction of Swift?
>> * If you have you used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>> * How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study? 
>> 
>> More information about the Swift evolution process is available at:
>>  https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> Thanks!
>> 
>> -Chris Lattner
>> Review Manager
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

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 class 
ultimately inherits from NSObject, it is always implicitly @objc, and applying 
@objc to a class not rooted in NSObject is always an error. (I think at some 
point in the past we allowed @objc classes that _don’t_ inherit from NSObject, 
but I don’t know if that even made it into any released version of Swift, so 
it’s totally vestigial at this point.) We can keep this behavior in Swift 3 
mode, but in Swift 4 mode, change things so that @objc applied to a class 
enables @objc inference for the members of the class, and the absence of @objc 
enables the new, more limited inference behavior outlined in this proposal.

Then the migration story can just be “slap @objc on every NSObject-derived 
class and you’re good”. Existing mixed source bases, KVC, and so on would just 
work. We could also say that in Swift 4 mode, @objc on an NSObject-derived 
class produces a warning asking the developer to consider making individual 
members @objc as necessary instead. This would allow a Swift 4 migration to 
proceed in two phases — first fix any fallout from SE-0110 or new string stuff 
or whatever, and get a working app that builds and runs in Swift 4 mode, albeit 
with some warnings. Then they can deal with marking individual class members as 
@objc later. We could still have the option of making it an error to apply 
@objc to an entire class in a future release of Swift, if we decide it is 
beneficial to do so.

Based on feedback, the all-or-nothing nature of the Swift 2->3 migration was 
rather painful — mixing and matching 3 and 4 modules will definitely help us do 
better the next time around, and allowing a complex change such as this one to 
be done piecemeal could be a further step in the right direction.

Slava

> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 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 process. All reviews 
> should be sent to the swift-evolution mailing list at:
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. 
> 
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a change to 
> Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have you used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study? 
> 
> More information about the Swift evolution process is available at:
>   https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thanks!
> 
> -Chris Lattner
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

> 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 allows some changes that could improve incremental 
> builds: the generated header ("MyApp-Swift.h") wouldn't need to be 
> regenerated nearly as often with fewer methods exposed to Objective-C. 
> (There's some nuance here that I don't need to go into right now, and there 
> are alternate solutions to that problem, but it's nice that the common case 
> will just put fewer declarations into the header and therefore it would 
> change less often.)
> 
> The migration aspect is a little scary. #selector's Objective-C equivalent is 
> @selector, which is easy to search for, but #keyPath maps to plain old 
> strings.

Are these strings usually literal strings that are passed in to some set of 
mostly-known selector names, or do people pass them around or even construct 
them dynamically?

Slava

> For those with Mac apps, properties might even be referenced in Interface 
> Builder using Cocoa Bindings. But limiting the change to Swift 4 mode seems 
> acceptable to me—at least it's a known change that people will be able to 
> point to when things stop working.
> 
> Jordan
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

> 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 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 feature that's just for supporting a specific other language.
>>> 
>>> My main concern is on whether things could be made a bit easier; 
>>> specifically I wonder whether we could introduce an option (to the 
>>> compiler?) to trigger warnings anywhere there is a possible missing @objc 
>>> attribute. Basically on any code that produces bridging headers this would 
>>> give a warning anywhere that @objc would have been inferred in the past, 
>>> but will no longer be. Of course this will generate a lot of warnings, but 
>>> it'll be an easier way for developers to go through and make sure they 
>>> didn't miss something. Xcode could offer this automatically during 
>>> migration, and the developer can turn it off when they're done. Not 
>>> perfect, but it may be a little extra help for those most affected?
>> 
>> The source compatibility section of the proposal
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md#source-compatibility
>> 
>> describes the use of NS_DEPRECATED in the generated header for Swift 3 
>> compatibility mode to get warnings on uses of entities that are implicitly 
>> @objc but will no longer be in Swift 4. Does that address your concern?
>> 
>> I’ve also heard the idea of putting the same warnings into the generated 
>> Objective-C thunks by NSLog’ing the same information as an opt-in, 
>> pre-Swift-4-migration step to help catch the tricky cases where an 
>> Objective-C entrypoint is getting called.
> 
> I would very much like that, mostly for catching all scenarios with bindings 
> on the Mac.
> 
> Otherwise, I agree with the proposal, just am a bit concerned with some of my 
> apps that heavily use bindings…

Perhaps a better solution than NSLog would be if the existing code coverage 
support could be modified to instrument @objc thunks, but I don’t know the 
details well enough to say if this would be practical to implement in the Swift 
4 time frame.

Slava

> 
>> 
>>  - Doug
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

> 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 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 
> bindings, sort descriptors, and predicates. Tons of migration errors are 
> going to escape into production if we do this, and undetectable mistakes are 
> going to continue on an ongoing basis. 
> 
> Have we explored alternate implementations? For instance, when the compiler 
> can statically determine all of the call sites for an `@objc` member, could 
> we emit *only* an implementation with the Objective-C calling convention and 
> call that directly from Swift?

This would incur bridging overhead for collections I believe. We really do want 
to use the Swift calling convention whenever we know the method is defined in 
Swift, even if happens to be exposed to Objective-C. It would be unfortunate if 
there was an unpredictable performance cliff encountered because of @objc 
inference.

> Have you evaluated applying different rules to methods and properties? Have 
> you considered a deprecation cycle (for instance, having Swift 4 thunks log a 
> warning that they're going away in Swift 5)?

I’m not sure how this could work. If we emit an unconditional warning on every 
method that has an Objective-C compatible signature but is not marked as @objc, 
how would the user acknowledge the warning and say “OK, I don’t really want 
inference here?” Would the only way to opt out of the warning be to write 
@nonobjc everywhere?

> Or is the real motivation that, code size issues aside, you think these 
> members ought to be explicitly marked `@objc` for philosophical reasons? If 
> so, how many times do you want people to say so? You already have to 
> explicitly inherit from an `@objc` base class; you already have to specify 
> `dynamic` to avoid optimizations; now you also have to mark individual 
> members `@objc`? Would you like the request for bridging notarized and filed 
> in triplicate?

The ‘accidental selector name clash’ argument is a good one I think; if you’re 
designing a pure Swift class that happens to inherit from NSObject, it might be 
confusing to a user if they define methods named foo(_: Int) and foo(_: String) 
and get a compiler error.

It would be interesting to get some more data on the size overhead of @objc 
thunks from real codebases, but I think the difficulty there is ascertaining 
which thunks are ‘required’ and which ones are not (which of course is also the 
core of your objection to the feature, if I understand; if we could perfectly 
determine which thunks were needed statically, the migration story would be far 
less of a concern).

Slava

> I can understand the impulse to require it explicitly on `public` members, 
> but on the other hand, if you *do* accidentally publish a member as `@objc`, 
> what's the harm? Is there any non-breaking change you can make to a 
> `@nonobjc` method which wouldn't be legal on an `@objc` one? Or can you just 
> deprecate the `@objc` version and move on?
> 
> Overall, I think this is far too bureaucratic, and I'm not convinced that 
> either the technical or the theoretical justification is compelling. Maybe 
> you've eliminated some of the possibilities I've suggested or there are 
> negative effects I don't understand, but right now, I don't see it. 
> 
>> * Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> 
> I'm uncertain. 
> 
>> * Does this proposal fit well with the feel and direction of Swift?
> 
> It fits with certain goals, like making public APIs explicit, but not with 
> others, like avoiding boilerplate. 
> 
>> * If you have you used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> I haven't used anything with such deep foreign-language bridging as Swift. 
> 
>> * How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study?
> 
> Quick reading during a hockey game, so please forgive any oversights. 
> 
> 
> Sent from my iPad
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> 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 side, and there are several different mechanisms 
there which use KVC with poorly validated external strings, like bindings, sort 
descriptors, and predicates. Tons of migration errors are going to escape into 
production if we do this, and undetectable mistakes are going to continue on an 
ongoing basis. 

Have we explored alternate implementations? For instance, when the compiler can 
statically determine all of the call sites for an `@objc` member, could we emit 
*only* an implementation with the Objective-C calling convention and call that 
directly from Swift?

Could members with binary-compatible signatures share a thunk? The Objective-C 
calling convention includes a selector parameter, so you can still determine 
the desired message.

Could we give implicit methods and properties a different, slower 
implementation that leverages Objective-C's dynamic features? Imagine, for 
instance, mapping in `imp_implementationWithBlock()`-style pages of 
general-purpose thunks at runtime to reduce code size, then installing them 
lazily with `+resolveClassMethod:`. (Maybe this could actually be made fast 
enough, amortized over all calls, that we could get rid of the thunks 
entirely—I don't know.)

Have you evaluated applying different rules to methods and properties? Have you 
considered a deprecation cycle (for instance, having Swift 4 thunks log a 
warning that they're going away in Swift 5)?

Or is the real motivation that, code size issues aside, you think these members 
ought to be explicitly marked `@objc` for philosophical reasons? If so, how 
many times do you want people to say so? You already have to explicitly inherit 
from an `@objc` base class; you already have to specify `dynamic` to avoid 
optimizations; now you also have to mark individual members `@objc`? Would you 
like the request for bridging notarized and filed in triplicate?

I can understand the impulse to require it explicitly on `public` members, but 
on the other hand, if you *do* accidentally publish a member as `@objc`, what's 
the harm? Is there any non-breaking change you can make to a `@nonobjc` method 
which wouldn't be legal on an `@objc` one? Or can you just deprecate the 
`@objc` version and move on?

Overall, I think this is far too bureaucratic, and I'm not convinced that 
either the technical or the theoretical justification is compelling. Maybe 
you've eliminated some of the possibilities I've suggested or there are 
negative effects I don't understand, but right now, I don't see it. 

> * Is the problem being addressed significant enough to warrant a change to 
> Swift?

I'm uncertain. 

> * Does this proposal fit well with the feel and direction of Swift?

It fits with certain goals, like making public APIs explicit, but not with 
others, like avoiding boilerplate. 

> * If you have you used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

I haven't used anything with such deep foreign-language bridging as Swift. 

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

Quick reading during a hockey game, so please forgive any oversights. 


Sent from my iPad
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

> 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 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 feature that's just for supporting a specific other language.
>> 
>> My main concern is on whether things could be made a bit easier; 
>> specifically I wonder whether we could introduce an option (to the 
>> compiler?) to trigger warnings anywhere there is a possible missing @objc 
>> attribute. Basically on any code that produces bridging headers this would 
>> give a warning anywhere that @objc would have been inferred in the past, but 
>> will no longer be. Of course this will generate a lot of warnings, but it'll 
>> be an easier way for developers to go through and make sure they didn't miss 
>> something. Xcode could offer this automatically during migration, and the 
>> developer can turn it off when they're done. Not perfect, but it may be a 
>> little extra help for those most affected?
> 
> The source compatibility section of the proposal
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md#source-compatibility
> 
> describes the use of NS_DEPRECATED in the generated header for Swift 3 
> compatibility mode to get warnings on uses of entities that are implicitly 
> @objc but will no longer be in Swift 4. Does that address your concern?
> 
> I’ve also heard the idea of putting the same warnings into the generated 
> Objective-C thunks by NSLog’ing the same information as an opt-in, 
> pre-Swift-4-migration step to help catch the tricky cases where an 
> Objective-C entrypoint is getting called.

I would very much like that, mostly for catching all scenarios with bindings on 
the Mac.

Otherwise, I agree with the proposal, just am a bit concerned with some of my 
apps that heavily use bindings...

> 
>   - Doug
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brian King via swift-evolution]

>
> * 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 section in "Source Compatibility" calls out a few
problems, presents some possible solutions, but states that they are "Out
of scope for this proposal". Given the depth of migration issues that this
proposal is expected to incur, I think leaving out these details feels
short-sighted. If this proposal is approved, when are the 'out of scope'
behaviors decided?

A few specific opinions on the possibilities presented:
- I'd like a clearer explanation on how the inferred `dynamic` behavior
would change. I would prefer @objc  to always infer dynamic or never infer
dynamic. Currently it's context dependent and confusing.
- I don't like forcing extension methods that are not `@objc` be flagged
`final`. That seems heavy handed.
- I'd like to get over-rides in extensions working!

That said, I'm new here, and I'm a net +0. I trust a good choice will be
made.


> * Is the problem being addressed significant enough to warrant a change to
> Swift?
>
Yes


> * Does this proposal fit well with the feel and direction of Swift?
>
Yes

* If you have you used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
>
No Experience


> * How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
In-depth study


>  More information about the Swift evolution process is available at:
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thanks!
>
> -Chris Lattner
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jordan Rose via swift-evolution]

[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-Swift.h") wouldn't need to be regenerated 
nearly as often with fewer methods exposed to Objective-C. (There's some nuance 
here that I don't need to go into right now, and there are alternate solutions 
to that problem, but it's nice that the common case will just put fewer 
declarations into the header and therefore it would change less often.)

The migration aspect is a little scary. #selector's Objective-C equivalent is 
@selector, which is easy to search for, but #keyPath maps to plain old strings. 
For those with Mac apps, properties might even be referenced in Interface 
Builder using Cocoa Bindings. But limiting the change to Swift 4 mode seems 
acceptable to me—at least it's a known change that people will be able to point 
to when things stop working.

Jordan
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Douglas Gregor via swift-evolution]

> 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 
> I think it's worth it to be more explicit about what's going on, and to clean 
> up a feature that's just for supporting a specific other language.
> 
> My main concern is on whether things could be made a bit easier; specifically 
> I wonder whether we could introduce an option (to the compiler?) to trigger 
> warnings anywhere there is a possible missing @objc attribute. Basically on 
> any code that produces bridging headers this would give a warning anywhere 
> that @objc would have been inferred in the past, but will no longer be. Of 
> course this will generate a lot of warnings, but it'll be an easier way for 
> developers to go through and make sure they didn't miss something. Xcode 
> could offer this automatically during migration, and the developer can turn 
> it off when they're done. Not perfect, but it may be a little extra help for 
> those most affected?

The source compatibility section of the proposal


https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md#source-compatibility

describes the use of NS_DEPRECATED in the generated header for Swift 3 
compatibility mode to get warnings on uses of entities that are implicitly 
@objc but will no longer be in Swift 4. Does that address your concern?

I’ve also heard the idea of putting the same warnings into the generated 
Objective-C thunks by NSLog’ing the same information as an opt-in, 
pre-Swift-4-migration step to help catch the tricky cases where an Objective-C 
entrypoint is getting called.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> 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 feature that's just for supporting a specific other language.

My main concern is on whether things could be made a bit easier; specifically I 
wonder whether we could introduce an option (to the compiler?) to trigger 
warnings anywhere there is a possible missing @objc attribute. Basically on any 
code that produces bridging headers this would give a warning anywhere that 
@objc would have been inferred in the past, but will no longer be. Of course 
this will generate a lot of warnings, but it'll be an easier way for developers 
to go through and make sure they didn't miss something. Xcode could offer this 
automatically during migration, and the developer can turn it off when they're 
done. Not perfect, but it may be a little extra help for those most affected?

> * Is the problem being addressed significant enough to warrant a change to 
> Swift?

I believe so, I think we need to cut down on anything that's too platform or 
legacy specific in favour of Swift being as clean and functional as possible 
with limited magic features.

> * Does this proposal fit well with the feel and direction of Swift?

Yes, as I believe it tidies up the language and removes something caters too 
much towards a specific, hopefully increasingly legacy, use-case.

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study? 

Following discussion, quick re-read.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Beck via swift-evolution]

* 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". Where there won't be errors or warnings,
I can imagine that behavior could change in ways that most people can't
predict.

* Is the problem being addressed significant enough to warrant a change to
Swift?
A 5% reduction in binary size is significant, and an issue that Swift is
certainly running into. However I suspect that there are other ways to
address this.

* Does this proposal fit well with the feel and direction of Swift?
Yes.

* If you have you used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?
N/A

* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
Read through the proposal.

On Tue, Mar 21, 2017 at 11:03 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 process. All reviews
> should be sent to the swift-evolution mailing list at:
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a change to
> Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have you used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
>  More information about the Swift evolution process is available at:
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thanks!
>
> -Chris Lattner
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Douglas Gregor via swift-evolution]

> 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 Objective-C thunks. The 
> motivation section says that this will reduce the reduce the binary sizes, 
> which is good, but should we expect not emitting those thunks will also 
> reduce by a bit the compilation times? Perhaps not by much, but I do think it 
> will.

I don’t think the effect on compilation time will be significant or noticeable. 
Although numerous, the thunks are fairly small and straightforward to 
produce/optimize/code-gen.

> 
> I'm already littering some projects with plenty of `@nonobjc` annotations 
> because I don't need those thunks. This proposal would allow me to make this 
> cleaner. Perhaps the migrator should remove the `@nonobjc` attributes when 
> they become unnecessary.

Yes, it could do that. 

> Actually, would the changes in this proposal make the `@nonobjc` attribute 
> irrelevant?

In practice, it would probably become mostly irrelevant. I suspect it would 
still find occasional use to suppress a warning about, e.g., a method that 
“almost matches” an optional requirement in an Objective-C protocol but that is 
not intended to match.

> 
> I'm a bit worried about the migration though.
> 
> I think it would be reasonable for the migrator to have two settings. A 
> conservative one that adds `@objc ` to all currently implicit `@objc` 
> declarations, to be used when you need to be absolutely certain everything 
> still works. Pruning of extra `@objc` would have to be done manually later, 
> if desired. And the default one that only adds `@objc` when the migrator sees 
> it as necessary.
> 
> I know I would always want to use the default migration setting. But it'd be 
> reassuring to have a safe fallback in case the migration breaks things.

I expect it’ll take some experimentation to get it right.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> * 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` is a great thing.

This has potential to be the rockiest feature to migrate to Swift 4 thus far.  
I like Michel’s idea of an option in the migrator to apply `@objc` everywhere 
it is inferred today.  This would help teams that rely on dynamic interactions 
with the Objective-C runtime to migrate safely.

> * Is the problem being addressed significant enough to warrant a change to 
> Swift?

Yes.  It cleans up semantics that can be confusing today and makes Objective-C 
interactions more explicit. 

> * Does this proposal fit well with the feel and direction of Swift?

Yes.

> * If you have you used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

There is a long history of bridging in the Apple ecosystem.  Annotation for 
bridged declarations is customary.

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study? 

A quick read.

> 
> More information about the Swift evolution process is available at:
>   https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thanks!
> 
> -Chris Lattner
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michel Fortin via swift-evolution]

> * 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 sizes, 
which is good, but should we expect not emitting those thunks will also reduce 
by a bit the compilation times? Perhaps not by much, but I do think it will.

I'm already littering some projects with plenty of `@nonobjc` annotations 
because I don't need those thunks. This proposal would allow me to make this 
cleaner. Perhaps the migrator should remove the `@nonobjc` attributes when they 
become unnecessary. Actually, would the changes in this proposal make the 
`@nonobjc` attribute irrelevant?

I'm a bit worried about the migration though.

I think it would be reasonable for the migrator to have two settings. A 
conservative one that adds `@objc ` to all currently implicit `@objc` 
declarations, to be used when you need to be absolutely certain everything 
still works. Pruning of extra `@objc` would have to be done manually later, if 
desired. And the default one that only adds `@objc` when the migrator sees it 
as necessary.

I know I would always want to use the default migration setting. But it'd be 
reassuring to have a safe fallback in case the migration breaks things.

> * Is the problem being addressed significant enough to warrant a change to 
> Swift?

The more Swift code there is in a project, the more important this change will 
be.

> * Does this proposal fit well with the feel and direction of Swift?

It will make semantics more predictable.

> * If you have you used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

A few years ago I wrote a bridge between D and Objective-C. I actually made two 
versions: one was based on D templates and generated a lot of thunks, and the 
second was integrated in the compiler and generated no thunks at all. The first 
one was creating bloated binaries in addition to being very slow to compile, 
while the second was very lean as it was mostly an Objective-C compiler using 
the D syntax.

I'm not expecting improvements of the same magnitude here, but emitting less 
unnecessary glue code is always a good thing.

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study? 

Quick reading of the proposal.

-- 
Michel Fortin
https://michelf.ca

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rien via swift-evolution]

+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 direction of Swift?

Neutral

> * If you have you used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

None

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study? 


Glance


Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 22 Mar 2017, at 07:03, Chris Lattner via swift-evolution 
>  wrote:
> 
> 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 process. All reviews 
> should be sent to the swift-evolution mailing list at:
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. 
> 
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a change to 
> Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have you used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study? 
> 
> More information about the Swift evolution process is available at:
>   https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thanks!
> 
> -Chris Lattner
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution