[swift-evolution] [Idea] Extend "required" to methods other than init()

[Matthew Johnson]

> On Jan 20, 2016, at 7:01 PM, Nate Birkholz via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I feel like leaving whether and when to call super up to the programmer is a more general solution. In my current codebase, calling super on an inherited method is what i *don't* want, instead overriding the whole method on every child.

In cases where it doesn’t matter whether super is called or not that works fine.  However, if the superclass is designed in such a way that certain methods must *always* be called if overrides it will lead to bugs when that doesn’t happen.  In these cases it would be nice if the compiler could enforce that for us.  In cases where you *don’t* want super to be called you would use an annotation like @no_super to make sure that it *isn’t* called by subclasses.

This comes down to whether we believe expressing and enforcing the intended override semantics in the language is worthwhile or not.  I believe it is.

-Matthew

> 
> On Wed, Jan 20, 2016 at 4:53 PM, Jesse Squires via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> Thanks Matthew and Howard! A lot of good points there.
> 
> There are certainly a few more possible semantics for overrides than I was initially thinking. It’s not clear to me if the language should support each use case or not. Doing so seems to add unnecessary complexity for (potentially) little gain.
> 
> I can’t say for sure, but my guess is that the *most common* scenario is: "if a method is overridden, it must call super first". This would also make automatically synthesizing the call to super simpler, which I think is a great idea. Clients then have less of a burden when subclassing.
> However, as noted, non-void returns complicate this. Also, I agree that re-purposing `required` could be confusing. I’m open to ideas for an alternative keyword.
> 
> Again, a lot of good ideas/feedback. I’m actually not sure where this leaves us. :) Accounting for all of the possible semantics seems too complex and burdensome, though I think our current state is insufficient. And perhaps accounting for only the simplest scenario, "if a method is overridden, it must call super first", would only further highlight the lack of ability to express the other possible semantics.
> 
> ¯\_(ツ)_/¯  I’d love to hear if anyone else has ideas or shares these concerns!
> 
> Jesse
> 
> 
> > On Jan 18, 2016, at 11:34 AM, Howard Lovatt via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >
> >>>
> >>> Are there other languages worth investigating which have the requires super first/last semantics you note?
> >>
> >> I don’t know of any languages that support this.  It is not the most common semantic, but when it occurs it seems important enough that it would be better if it could be specified in the language itself and enforced rather than left to documentation.
> >
> > BETA has this ability, but it worked rather differently than modern OO languages (which work more like its predecessor Simula). In BETA you can only ever call the top most method, it can then optionally call the immediately overriding method. The syntax BETA uses is `inner(<args>)`. Probably easier with examples (in BETArised Swift):
> >
> >    class Base {
> >        func finalM() { print("finalM") }
> >        func mustOverrideM() {
> >            print("beforeInner")
> >            inner()
> >            print("afterInner")
> >        }
> >    }
> >
> >    class Derived: Base {
> >        func mustOverrideM() {
> >            print("inInner")
> >        }
> >    }
> >
> > Methods `finalM` and `Derived.mustOverrideM` are automatically final because they do not call inner.
> >
> > You can't make an instance of `Base` because method `Base.mustOverrideM` needs to be overridden, i.e. `Base` is automatically abstract.
> >
> > If you:
> >
> >    let d = Derived()
> >    d.mustBeOverriddenM()
> >
> > Then it prints:
> >
> >    beforeInner
> >    inInner
> >    afterInner
> >
> > _______________________________________________
> > 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>
> 
> 
> 
> -- 
> Nate Birkholz
> _______________________________________________
> 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/20160120/b21993c3/attachment.html>