[swift-evolution] Proposal: Add @requires_super attribute
Etan Kissling
kissling at oberon.ch
Wed Dec 16 11:25:44 CST 2015
Or simply make `throws` and `requires_super` mutually exclusive?
The case where the base class does not `throw` but the subclass `throws` isn't possible
as it would break all clients who cast everything to the base class and assume that it doesn't throw.
Etan
> On 16 Dec 2015, at 17:46, Marc Knaup via swift-evolution <swift-evolution at swift.org> 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/982fb149/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/982fb149/attachment.sig>
More information about the swift-evolution
mailing list