[swift-evolution] Enhancing access levels without breaking changes

[Tony Allevato]

Extensions can already do what partials would do, and more—Swift does not
need two features that are almost the same but with subtle differences when
it comes to the visibility of its members. That seems like something that
will only cause confusion for users. Partials feel like trying to shoehorn
a feature from another language into Swift to solve an unrelated problem.

Swift 2 and 3 have never had type-oriented visibility—they've only had
visibility that covered contiguous regions of the symbol space ("the
universe", "the module", "the file", and then in Swift 3, "the enclosing
scope"). Being able to split a type's *scope* with partials (as opposed to
just the type itself with extensions) across multiple files files would be
quite inconsistent with how visibility in Swift has been so far.

At some point, we need to come to grips with the fact that there are going
to be keywords we think are a little ugly (I much preferred the original
definition of "private", but "fileprivate" is part of Swift now and I've
moved on) and that there's never going to be a way to perfectly audit
visibility of every single member that we write in a way that makes
everyone happy.

I don't want to sound dismissive, but I feel like it's simply not
productive to keep rehashing visibility over and over again.


On Mon, Apr 10, 2017 at 7:20 AM Jose Cheyo Jimenez via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> On Apr 10, 2017, at 12:20 AM, David Hart via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On 10 Apr 2017, at 08:21, Jean-Daniel <mailing at xenonium.com> wrote:
>
>
> Le 10 avr. 2017 à 07:15, David Hart via swift-evolution <
> swift-evolution at swift.org> a écrit :
>
>
>
> On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Apr 9, 2017, at 7:14 PM, Jonathan Hull via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> This struck me as a bit odd at first, but the more I think about it, the
> more I really like the ability to nest extensions/scopes.  The one issue I
> see is sticking that public extension inside a private one.  I think you
> would have to mark ‘secret: Int’ as private instead of the extension itself
> to allow the effect you are looking for...
>
> What I ultimately want is the ability to declare storage in extensions in
> the same submodule. Combining that with fileprivate will allow the same
> tricks without the indentation (together in their own file).  This nesting
> will help in the mean-time (and would still be useful after for those who
> prefer to organize their code in fewer/longer files).  I think it could be
> helpful in other ways too…
>
>
> What do you think of `partial` types like C# but limited to a file?
> https://msdn.microsoft.com/en-us/library/wbx7zzdd.aspx
>
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035360.html
>
>
> That's the direction the new proposal (0169) is going towards with
> extensions in the same file.
>
>
> I don’t see how SE-0169 do that more than any other meaning private got
> until now. This was already the case with the initial meaning of private,
> and was the case with fileprivate.
>
>
> The current semantics of private don’t give any support for partial types
> like in C# because the accessibility is restricted to the current scope.
> With SE-0169’s private, extensions in the same file as the type share that
> scope. Plus, the *Alternatives Considered* section of the proposal
> discusses potential future directions where those extensions could look
> even more like C# partials :)
>
>
> SE-169 could be emulated cleanly by introducing partial types within the *same
> scope* as a new feature completely separate from extensions. Partial
> types would not require redefining how private or extensions work now. It
> would also serve as a way to communicate to the user that the type is not
> done being defined so if they want to encapsulate the type completely, They
> have to make it non partial.
>
>
>
>
>
>
> And for file splitting and visibility control, we need submodules. Until
> then, if this proposal is to define the ultimate meaning of private, I
> rather like this meaning that the SE-0025 one.
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170410/4885bea7/attachment.html>