[swift-evolution] Proposal: Add @requires_super attribute

[Jordan Rose]

+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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> 
> 
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/769aed4b/attachment.html>