On Mon, Jul 18, 2016 at 2:59 AM, Goffredo Marocchi <[email protected]> wrote:
> Hello Xiaodi, > > A general principle of Swift, recently strengthened by proposals such as > SE-0117 > <https://github.com/xwu/swift-evolution/blob/harmonize-access-modifiers/proposals/0117-non-public-subclassable-by-default.md>, > has been that public API commitments should require explicit opt-in. Given > the different behavior of classes and structs, the fact that extensions > allow public methods to be declared without spelling out public at the > declaration site has been called "confusing" or "odd." > > > I think this is slightly misleading as that proposal dealt with classes > being sealed by default outside of the current module while from your > summary this would be also an explicit call for final by default which is > not something the core team said explicitly or that the Swift community > largely agrees with. > Sorry, I will edit to clarify that sentence. My thinking was, Swift is already internal by default; SE-0117 has added another layer, so that it's internal -> public -> public open. In my mind, that's strengthening in that the opt-in process for public APIs is now even more fine-grained. > > Sent from my iPhone > > On 18 Jul 2016, at 08:50, Xiaodi Wu via swift-evolution < > [email protected]> wrote: > > A general principle of Swift, recently strengthened by proposals such as > SE-0117 > <https://github.com/xwu/swift-evolution/blob/harmonize-access-modifiers/proposals/0117-non-public-subclassable-by-default.md>, > has been that public API commitments should require explicit opt-in. Given > the different behavior of classes and structs, the fact that extensions > allow public methods to be declared without spelling out public at the > declaration site has been called "confusing" or "odd." > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
