[swift-evolution] Proposal: Universal dynamic dispatch for method calls

[Matthew Johnson]

> No problem, I’m taking time to pontificate here for the benefit of the community, hopefully it will pay itself back over time, because people understand the rationale / thought process that led to Swift better :-)


I appreciate these philosophical musings about language design greatly!  They make for very interesting reading and definitely shed more light on some of the decisions made in the design of Swift.

> You can also think about the feature in terms of common metrics by asking things like “what is the error of omission?” which occurs someone fails to think about the feature.  For example, if methods defaulted to final, then the error of omission would be that someone didn’t think about overridability, and then discovered later that they actually wanted it. 


In this example I think it is reasonable to consider “what is the error of omission?” from the reverse standpoint.  Because methods do not default to final somebody may not think about inheritance / overridability and fail to specify final.  The class or method may be one that really should not be inheritable / overridable or it may be one where this is reasonable, but the implementation is not well designed to support this.  In this case they may later discover that they have buggy subclasses upon which a lot of code depends. IMHO this is much more serious than discovering that one should have allowed inheritance / overridability which can be added with a non-breaking change (from a semantic point of view, maybe implementation is not so simple when ABI resilience is a requirement).

Inheritance is a pretty complex tool to wield *without* prior consideration IMHO.  Swift already offers a lot of tools that reduce the need for inheritance and will hopefully offer more in the future (such as improved protocols / generics, better support for composition through synthesized forwarding, etc).  Why not *require* some forethought to use inheritance?  This would provide subtle guidance towards other solutions where appropriate just as Swift subtly guides users towards immutability.

As an aside, final is actually the right choice for the majority of classes I encounter in iOS apps.  This may not always be the case in system frameworks but they *should* receive much more careful design than application level code.  

Please don’t take this as pedantic.  I’m genuinely curious to hear more about why you apply “error of omission” one way and not the other in this case.

Thanks,
Matthew