> The problem with this is simple: you cannot retroactively "close up" an API.
> I cannot add final to a class I have previously declared as non-final. I also
> can seal a class which has previously been open to subclassing.
Of course you can do both — it may make users angry, but so what?
The essence of this way of thinking is "I fear the reaction of my users when I
take something away from them… so I have to deny them those options right from
start".
I've no statistics (there's a general lack of facts all over the place…), but I
don't thing the majority of todays and future libraries are build with a
strictly planned top-down approach and guarantees about API-stability. Nowadays
things are much more spontaneous, and the strict rules and limits some people
here want to force upon others would most likely decrease the joy in playing
with the language and start experiments in it.
There is only a very small number of Swift-developers writing frameworks that
are used on a large scale basis, and even if many people in this group vote for
limiting defaults, the focus should be on the majority:
When I come to the conclusion that a set of classes in a project could be
useful somewhere else, my problem is not fear of future API changes — it is the
daunting task of having to sprinkle "public" all over the place.
Sealing classes makes proper code reuse a more tedious job, and I want Swift to
stay fun rather than become a playground for sticklers for order.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
