[swift-evolution] [Draft] Harmonize access modifiers for extensions

[Xiaodi Wu]

On Mon, Jul 18, 2016 at 2:59 AM, Goffredo Marocchi <panajev at gmail.com>
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 <
> swift-evolution at swift.org> 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."
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160718/12f27efa/attachment.html>