[swift-evolution] [Review] SE-0025 Scoped Access Level

[Ilya Belenkiy]

> I admit I was surprised by the semantics of private in Swift when I first
discovered it,

And so will be most of newcomers.

> But I’ve not been overly bothered by it, and I’ve always kept a fairly
strict one class per file > anyway.

It is still useful to have "scoped" in one class per file structure. If the
code is organized in a way where internal state is hidden in one scope and
other functions that don't require access to the internal state are added
via extensions, "scoped" can hide the internal state from extensions and
also hide implementation details of each extension from other extensions in
the same file.

> I also don’t like that the proposal adds another keyword/layer of scoping.

Today, there is no other way to express what "scoped" does except
by putting each scope into a separate file. This is very restricting and
makes it more difficult to put related code in the same file (you lose any
the help that the compiler could give you with protecting against using
private APIs).

> If people really wanted Scoped Access Level, I would have suggested
modifying the meaning > of private to correspond to Scoped Access Level and
not add another keyword like this > proposal.

"private" as it is today serves an important purpose of allowing access to
internal state of related classes. It solves the same problem as "friend"
in C++. "scoped" is necessary to hide implementation details completely,
regardless of where the code is.

> I don’t find it worthwhile enough to warrant adding another scoping level
and confusing > newcomers.

You acknowledge that the meaning of "private" is already confusing to
newcomers from other languages. Having "scoped" would only reduce the
confusion by providing what newcomers are likely already used to. If we
could rename "private" to something else that clearly means "file level
access", there would be no confusion at all. Newcomers would just map
"private" that they are used to in other languages to "scoped" in Swift.

> Yes, all the other languages I have used have had Scoped Access Level,
but I don’t mind > Swift’s current file access level.

Neither do I. I think it's great to have a file based access level. It
might be better than "friend" in C++. "scoped" provides the functionality
similar to "private" in C++ and is valuable because it would provide
clarity of intent that can be enforced by the compiler and help ensure code
correctness.


On Sun, Feb 28, 2016 at 2:08 PM David Hart via swift-evolution <
swift-evolution at swift.org> wrote:

> *What is your evaluation of the proposal?*
>
> -1
>
> I admit I was surprised by the semantics of private in Swift when I first
> discovered it, because I was used to private in other languages
> corresponding to Scoped Access Level. But I’ve not been overly bothered by
> it, and I’ve always kept a fairly strict one class per file anyway. I also
> don’t like that the proposal adds another keyword/layer of scoping. If
> people really wanted Scoped Access Level, I would have suggested modifying
> the meaning of private to correspond to Scoped Access Level and not add
> another keyword like this proposal.
>
> *Is the problem being addressed significant enough to warrant a change to
> Swift?*
>
> I’d say no.
>
> *Does this proposal fit well with the feel and direction of Swift?*
>
> I don’t find it worthwhile enough to warrant adding another scoping level
> and confusing newcomers.
>
> *If you have used other languages or libraries with a similar feature, how
> do you feel that this proposal compares to those?*
>
> Yes, all the other languages I have used have had Scoped Access Level, but
> I don’t mind Swift’s current file access level.
>
> *How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?*
>
> A thorough read.
> _______________________________________________
> 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/20160228/f6558dae/attachment.html>