[swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Gwynne Raskind]

Agreed as well. This is one of the most contentious topics I’ve seen come across Swift so far. While there may be no stopping the avalanche now as far as implementing the proposal in general (which I remain against, though many of the arguments I’ve heard in favor of it are starting to shake my conviction!), it definitely begs more consideration than running up hard against a release deadline. Goes double considering the disagreement even among the proposal’s supporters about the best semantics.

This being said, for the record, in the current version of the proposal I’d prefer option 1 over option 2 (if I’m not allowed to naysay the whole thing). Option 2 strikes me as a halfway measure; if we really are going to do this, then let’s *do* it.

(And as a general statement, I agree that in that context, "open" should be its own access level. I don’t mind having 5 access levels as long as they’re clearly defined.)

-- Gwynne Raskind



> On Jul 25, 2016, at 09:43, Davor Jankolija via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I have to agree with what Scott said. At this point it really does seem a bit rusked just to meet the Swift 3 deadline. There will certainly be breaking changes in Swift 4, 5 etc… so although I understand the reasoning to get as many of these into Swift 3, IMO now it’s just trying to rush the proposal at the cost of perhaps more discussion.
> 
> P.S. 
> I’m entirely in favor of the idea and reasoning behind the proposal and feel that a way to prevent all classes being subclassable even if they’re declared public is a worthwhile notion.
> 
> — Davor
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution