[swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy]

-1, "external" can be also understood as "exported" or public. I think that
the names in the updated proposal are the clearest. Also, I think that at
this point we need to stop trying to come up with more names. I don't think
that we will ever reach a point where everybody is happy with the names.
The ones that we have now seems to be a good compromise that is in line
with other Swift keywords.
On Tue, Mar 29, 2016 at 9:23 AM Paul Ossenbruggen via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Mar 29, 2016, at 12:32 AM, Andrey Tarantsov via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> public (unchanged)
> external (module access)
> internal (file access)
> private (scoped access)
>
>
> This seems logical and something I could live with, but how is it better
> than moduleprivate and fileprivate? Also, internal has contradictory prior
> art in C# and Swift 2 (not that it stops us).
>
> And I see the length of moduleprivate and fileprivate as a feature, and
> external/internal lacks it.
>
>
> It is better than moduleprivate and fileprivate in that it is a single
> word which is easier to to read and there is less typing. Less typing even
> with autocomplete is a benefit. Once you know its meaning, that both are
> relative to file access, you won’t have to look it up. Also, just noticed
> this, when I type multiword keywords in an email program or chat program
> autocorrect butts in. This is of practical value because much work is done
> in chat and email programs.
>
> Simpler is better if it sufficiently conveys the meaning and it does in
> this case. The expectation with most keywords are that they be single
> words, especially ones that are used the most.
>
> There is a nice symmetry to internal/external and public/private.
>
> If external/internal refer to the file, then we don’t need the multiword
> descriptive versions.  Also, if we decide later that scoping to namespaces
> is desired these same already reserved keywords give us more flexibility
> than the more specific keywords would allow. Internal/external could refer
> to the namespace scope rather than the file scope if it is inside a
> namespace (this is beyond the scope of the proposal but trying to think
> ahead). By not explicitly stating the scope you gain flexibility
>
> - Paul
>
> _______________________________________________
> 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/20160329/1f70cdb6/attachment.html>