Well, I walked into that one :( Sorry to trawl all that up on a Sunday. I get it now. “open” is the new “public”, “public, the new “final” at least as far as classes outside the module are concerned.
John > On 15 Aug 2016, at 10:51, Tino Heth <2...@gmx.de> wrote: > > >> Am 14.08.2016 um 14:59 schrieb Jean-Denis Muys via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: >> >> This decision is bad, not because it makes the default for classes to be >> unsubclassable > > Seems that the prediction of the grief caused by SE-0117 in the long run was > right ;-) — but be careful, the title doesn't reflect reality anymore: > As far as I understand, the default won't be changed at all. > It has been internal, and it will be internal. > The change is that changing the default to "public" will only make a > class/method visible outside the current module, without the right to > subclass/override. > So, basically, "public" is renamed to "open". > Imho this is still causing unnecessary trouble, as it breaks most libraries > out there (more precisely: Third party code that relies on the old behavior), > but in the future, you can just use "open" instead of "public", and little > else will change — except that users of your framework may assume that "open" > is an extension of "public", whereas you may follow the notion that "public" > is an restriction of "open". > > In the end, imho the whole topic has been decided in a very Solomonic way > that disappoints both parties ;-), so I don't think it will be a reason for > someone to fork Swift.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
