> On 20 Nov 2016, at 16:00, Tino Heth <2...@gmx.de> wrote:
>
>
>> I'm not sure I follow your meaning on omission; I quite like Sean's
>> suggestion of having an override(before) or override(final) in the
>> sub-class, this way the call is explicitly auto-generated. I think having it
>> be added automatically in the regular override case could be a bit
>> confusing, I think a warning or error is better in that case as it should be
>> visible so you know exactly when it is being called, the other cases don't
>> need it (as they have the extra information on the override).
> It's always possible to construct examples where there order is important,
> but I guess those won't matter in real code — and it would feel very strange
> to me if one of the print-statements would cause an error:
> override func f(input: Int) {
> print("Before")
> super.f(input: input)
> print("After")
> }
>
> (even commands after a return statement compile just fine…)
I think I covered that, though it's a bit of a tricky situation; ideally a
restriction shouldn't cause either of those print statements to cause an error,
as they have no side-effects to self. The problem is detecting that, as we
don't currently have any exposure of pure functions, and no way of knowing that
a method of a reference type is mutating or non-mutating yet. I've raised it
mainly for discussion as I'm not 100% sure of what we'd need to make it work.
If it isn't possible just yet though then the before and after attributes could
always be delayed until later when non-mutating reference methods and pure
functions can be reliably accounted for. This means that an initial release
would be for the required, optional and never attributes to determine whether
super has to be called, and error/warning to tweak the severity of that
restriction.
I do still like the idea of allowing sub-class developers to use
override(before) and override(after) to generate the super call for them
regardless; while it may seem minor it allows you to focus in on what you're
changing, but does have the slight added advantage of being its own scope, i.e-
since you mentioned defer before, in an override(after) method the defer would
be called before the automatic super method.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
