>> 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
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
