> On Mar 23, 2017, at 9:03 AM, Charlie Monroe <char...@charliemonroe.net> wrote:
>
>>
>> On Mar 23, 2017, at 9:44 AM, Slava Pestov <spes...@apple.com
>> <mailto:spes...@apple.com>> wrote:
>>
>>>
>>> On Mar 22, 2017, at 10:34 PM, Charlie Monroe via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>>>
>>>> On Mar 23, 2017, at 12:02 AM, Douglas Gregor via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>
>>>>
>>>>> On Mar 22, 2017, at 3:22 PM, Haravikk via swift-evolution
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>
>>>>>
>>>>>> On 22 Mar 2017, at 06:03, Chris Lattner via swift-evolution
>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
>>>>
>>>> <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
