[swift-evolution] Proposal: Add @requires_super attribute

[Vester Gottfried]

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