[swift-evolution] Proposal: Add @requires_super attribute

[T.J. Usiyan]

+1

I thought that there must have been some reason not to include it that I
hadn't considered when it wasn't in Swift 1.0.

On Wed, Dec 16, 2015 at 1:59 PM, Jordan Rose via swift-evolution <
swift-evolution at swift.org> wrote:

> 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> 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> 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> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>> _______________________________________________
>> 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/3cb93572/attachment.html>