[swift-evolution] Final by default for classes and methods

[Matthew Johnson]

Sent from my iPad

> On Dec 22, 2015, at 3:43 AM, Tino Heth <2th at gmx.de> wrote:
> 
> 
>> I can see why you view it this way, but access control and inheritability are orthogonal.
> as I understand orthogonal (mathematical background), it is definitely not the case:
> I can't inherit what I cannot access, so there is one impossible combination of the two attributes.

Ok, you got me there.  Orthogonal was not the best choice of words.  Nevertheless, they are independent concerns that happen to interact in this one case.

> 
> The argumentation that "users of your framework could cause trouble (what they will do anyways ;-) with overriding" looses traction when you have to add "of cause that only applies to classes you made explicitly accessible to them".
> 
> Final is right in theory, but in real software, classes are rarely designed for inheritance — it just happens (and I'm quite sure most real software is build by people who would shrug of such discussions as academic nonsense ;-).

If the time comes it is certainly a good thing if the language can remind you of the fact that you didn't consider it in the initial implementation by requiring you to mark the superclass inheritable.

> 
> Btw: I wouldn't oppose a proposal to allow changing conventions like this (there are at least two other discussions about the best default) on a per module/file basis — as long as the "local" effect of the setting isn't vital, there shouldn't be a problem with customizing.

I would really be opposed to this.  It would not be clear when reading code what it actually means.  Copy and paste would also be problematic for similar reasons.  Flags should not change the semantics of a piece of code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151222/9ef3a921/attachment.html>