[swift-evolution] Proposal: Add @requires_super attribute

Wed Dec 16 12:59:38 CST 2015

My hesitation about "required" is that required initializers don't have to call the same initializer, which is something that NS_REQUIRES_SUPER does enforce. (In fact, this new attribute could very well apply to required initializers as well: if you implement this initializer, you must chain to the same initializer. I'm not quite sure when that would come up, but it's potentially useful.)

Jordan

> On Dec 16, 2015, at 10:56 , Ian Ynda-Hummel via swift-evolution <swift-evolution at swift.org> wrote:
> 
> +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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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>
> 
> 
> 
>  _______________________________________________
> 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
> 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/c1e567b5/attachment.html>