[swift-evolution] Proposal: Add @requires_super attribute

[Marc Knaup]

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/e03d3db3/attachment.html>