[swift-evolution] Proposal: Add @requires_super attribute
Matthew Johnson
matthew at anandabits.com
Wed Dec 16 12:00:16 CST 2015
Calling super asynchronously would not meet an @requires_super specification IMO. I would interpret it to mean you must call super before returning.
The compiler already guarantees all code paths return and guarantees subclass initializers call super. I don't think a sensible definition of @requires_super would be any more complex than that.
Sent from my iPad
> On Dec 16, 2015, at 11:49 AM, Marc Knaup <marc at knaup.koeln> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/570ceed9/attachment.html>
More information about the swift-evolution
mailing list