Please stop saying that this proposal will bring more consideration to the
design of libraries. It isn’t true. I haven’t even seen an argument for why
it would be true, it is just taken for granted that it is true.
As I mentioned in another post, this is structurally very different from things
like ‘if-let’ and optionals. Optionals force the user to consider their
decision in the context it is being used (i.e. as you use the optional/value).
This proposal, however, does the opposite. The effect of your actions appear
in the context of a completely different user. It is like sitting in a room,
flipping a light switch wondering “I wonder what this does?”… meanwhile the
people downstairs are wondering why their lights keep turning off and on”.
You can try to test for this, but by definition library authors can only test
for scenarios that they have thought of. I have often found people surprise me
with their use-cases. Relying on the diligence of other programmers is what
leads to things like: "You always need to remember to test for zero before
using a pointer". Literally the opposite of optionals! It sounds good, but at
the end of the day, people are human and they WILL make mistakes. Best to
either catch those mistakes in the context where they happen or to mitigate the
effect of it. This proposal basically forces you to feel the full effect of
other people's mistakes (thinking that it will discourage them from making them
in the first place).
Your only real mechanism for feedback is when users of your library complain to
you that something that they need isn’t subclass-able. This is the point where
most framework authors will actually learn that this feature/default exists.
Users of a framework will learn of it slightly earlier, when they find they
need to subclass something, and it just isn’t possible.
I would much prefer adding a ‘sealed’ keyword which library authors could use
to annotate things which they do not want subclassed outside of the module. Or
preferably, as others have suggested, allow augmentation of ‘final’ with
‘public(final)' or ‘internal(final)’.
The only case where I would support ‘sealed’ by default is if there are 3
levels: open, sealed, final. Final would allow 'public(final)' and
'internal(final)’ to allow private subclassing inside the file/module. Sealed
would be the same, except it would allow the user to subclass by explicitly
acknowledging the risk using ‘unsafe’: “unsafe class MySubclass:SealedSuper“
and “unsafe override func”. Final would not allow the override.
That is the case where ‘sealed’ makes sense as a default…
Thanks,
Jon
P.S. The current proposal will only cause massive problems down the line, IMHO.
We will find an escape hatch is needed, but we will have made optimizations
based on assumptions of finality which prevent us from easily adding one.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
