[swift-evolution] Proposal: Add @requires_super attribute

[Ian Ynda-Hummel]

+1 for this if for nothing else but UIKit classes yelling at me to call
super.viewDidLoad().

I think using the required keyword makes sense. The one possible caveat is
overloading, as my knee jerk reaction is that methods of the same name
would behave like initializers. So a method overriding a required method
would have to call a required method of the same name on the superclass if
one exists. I'm not convinced that's correct, though.

On Wed, Dec 16, 2015 at 1:40 PM Marc Knaup via swift-evolution <
swift-evolution at swift.org> wrote:

> "required" also doesn't mean that a subclass has to implement the required
> initializer since it can be inherited.
> Your example is an abstract function which should have it's own keyword
> (if we ever get abstract functions).
>
> On Wed, Dec 16, 2015 at 7:37 PM, Vester Gottfried <
> vester.gottfried at gmail.com> wrote:
>
>> I think reusing required would send the wrong message. Required would
>> mean for me something like NSOperation subclasses maybe require to have a
>> main() function, but that doesn't mean you have to call super. On the
>> contrary, the documentation of NSOperation main() explicitly states not to
>> call super.
>>
>> On Wed, Dec 16, 2015 at 7:08 PM, Marc Knaup <marc at knaup.koeln> wrote:
>>
>>> What about re-using the "required" keyword in the superclass which
>>> already means something similar for initializers?
>>> Subclass implementations are required to call super's implementation.
>>> If a subclass doesn't implemented the required method it could mean that
>>> it inherits the behavior from the superclass - just like initializers can
>>> be inherited too.
>>>
>>> On Wed, Dec 16, 2015 at 7:02 PM, Jordan Rose <jordan_rose at apple.com>
>>> wrote:
>>>
>>>> +1 from me. FWIW, the Objective-C one is syntactic.
>>>>
>>>> Information from Radar: the request for this is rdar://problem/17408107
>>>> (plus a few duplicates). One of the dups suggests a variation where a
>>>> subclass method can be declared as "refine" instead of "override" so that
>>>> you can document that your *own* method is expected to call super. In
>>>> this model, "@requires_super" could become something like "imposed". I
>>>> personally think this doesn't add enough, especially since we wouldn't be
>>>> publishing refine-vs-override in a library's public interface.
>>>>
>>>> Jordan
>>>>
>>>> On Dec 16, 2015, at 9:49 , Marc Knaup via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>>
>>>> Sounds reasonable since even the best flow analysis cannot ensure that
>>>> all codepaths call the super implementation.
>>>>
>>>> Some more edge cases:
>>>>
>>>>    - Calling super asynchronously by using it in a closure
>>>>    - Referring to the super implementation by assign it to a variable
>>>>    and call it later (is that really possible? never did that)
>>>>
>>>>
>>>> On Wed, Dec 16, 2015 at 6:25 PM, Vester Gottfried <
>>>> vester.gottfried at gmail.com> wrote:
>>>>
>>>>> I would suggest that @requires_super only checks if a call to super is
>>>>> present at all. More detailed behaviour should be part of the functions
>>>>> documentation, because I think all possibilities cannot be checked easily
>>>>> by the compiler. For example a call to super my be required to happen early
>>>>> or late inside the function. But when too early or too late is can probably
>>>>> not been forseen by the compiler.
>>>>>
>>>>> On Wed, Dec 16, 2015 at 5:46 PM, Marc Knaup <marc at knaup.koeln> wrote:
>>>>>
>>>>>> +1 always had such issues with UIViewController's lifecycle methods.
>>>>>>
>>>>>> But edge cases need to be considered like "throws" for example.
>>>>>> Do I need to call super before I throw something?
>>>>>>
>>>>>> On Wed, Dec 16, 2015 at 5:41 PM, Matthew Johnson via swift-evolution
>>>>>> <swift-evolution at swift.org> wrote:
>>>>>>
>>>>>>> +1 to this.  Anything that helps ensure inheritance is thought
>>>>>>> through carefully and used correctly is a win.
>>>>>>>
>>>>>>> On Dec 16, 2015, at 10:32 AM, Vester Gottfried via swift-evolution <
>>>>>>> swift-evolution at swift.org> wrote:
>>>>>>>
>>>>>>> Some class based libraries/frameworks expect the consumer to
>>>>>>> subclass certain classes and override specific method and require that the
>>>>>>> super implementation of an overridden method is being called.
>>>>>>>
>>>>>>> Not calling the super implementation is a common source of bugs that
>>>>>>> may be prevented if the compiler checks if super is called, like it does in
>>>>>>> some cases of init().
>>>>>>>
>>>>>>> Example:
>>>>>>>
>>>>>>> class Box {
>>>>>>>    @requires_super
>>>>>>>     func addStuff() { ... }
>>>>>>> }
>>>>>>>
>>>>>>> Overriding class Box's addStuff without calling super.addStuff()
>>>>>>> should result in an error
>>>>>>>
>>>>>>> class Chest : Box {
>>>>>>>     override addStuff() {
>>>>>>>          // ERROR: addStuff() requires call to super.addStuff()
>>>>>>>         ...
>>>>>>>     }
>>>>>>> }
>>>>>>>
>>>>>>> Objective-C developers know this as NS_REQUIRES_SUPER and I think
>>>>>>> its worth thinking about adapting it.
>>>>>>>
>>>>>>> I hope my proposal was clear and thanks for reading,
>>>>>>>
>>>>>>> Gottfried
>>>>>>>  _______________________________________________
>>>>>>> swift-evolution mailing list
>>>>>>> swift-evolution at swift.org
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> swift-evolution mailing list
>>>>>>> swift-evolution at swift.org
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>  _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>>
>>>>
>>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/c0d0e8fa/attachment.html>