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

[Howard Lovatt]

Scala has a sophisticated and interesting access level that might well be
good fit to Swift (since the two languages are very similar), e.g
Swiftizing some Scala:

class society {

class professional {

class Executive {

private(society) var friends = ...

private(professional) var workDetails = ...

private var secrets = ...


func executive() {

print(friends) // OK inside society

print(workDetails) // OK inside professional

print(secrets) // OK inside Executive

}

}

func professional() {

           print(friends) // OK inside society

           print(workDetails) // OK inside professional

           print(secrets) // ERROR outside Executive

}

}

func society() {

           print(friends) // OK inside society

           print(workDetails) // ERROR outside professional

           print(secrets) // ERROR outside Executive

}

}

var exec = society.professional.Executive()


print(exec.friends) // ERROR outside society
print(exec.workDetails) // ERROR outside professional
print(exec.secrets) // ERROR outside Executive


In Scala access is:

   1. public, private, or private(S); plus protected for abstract classes
   and private(self) for generic classes with generic variance - neither
   relevant to this discussion
   2. public behaves as expected
   3. The default is public, therefore in the example above society,
   professional, Executive, and the functions are all public
   4. private is scoped so that is only visible within its enclosing scope,
   hence secrets is only visible inside Executive
   5. private(S) extends the visibility to the named enclosing scope S,
   hence workDetails is visible inside professional's scope because it is
   declared private(professional)

If Scala style access modifiers were adopted for Swift then a private(file)
modifier would also be necessary to give the current private functionality.

Note Scala has modules, called packages, and in the Scala example I copied
and converted to Swift above the society and professional classes were
packages and hence there lower-case spelling. Class was the nearest
substitute in Swift for a scala package. The original Scala is from:
http://www.tutorialspoint.com/scala/scala_access_modifiers.htm

  -- Howard.

On 29 March 2016 at 07:30, Jordan Rose via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Mar 28, 2016, at 11:40, Ilya Belenkiy <ilya.belenkiy at gmail.com> wrote:
>
> > I *still* don't understand your reasoning here. If a private member can
> be used in a member function, and in closures inside that member function,
> why can't it be used in a member type?
>
> The simplest answer is that it's the most private access level, and also
> one that doesn't create any confusion. We already discussed several times
> here whether inner should have access to outer or the other way around.
> With this design, the answer is neither.
>
> A longer answer is that if you move a function into a type and make it a
> member function, you change the semantics. It's no longer the same
> function. If you move the type inside another type, the semantics is the
> same. The only difference is that we get shorter names. Also, if you move a
> function to be a member function, that changes the class API. If you move a
> class to become a nested class, that does not change the outer class API.
> Both classes can be used the same way but with different spelling of the
> name of the inner class.
>
> Also, I think that the terminology of access level really comes from OOP.
> The problem with the current state of things is that it mixes this
> terminology with export levels. This proposal makes "private" mean what it
> means in OOP and extends it so that it makes sense with Swift extensions.
>
> If we were talking about "scoped" level access, the immediate scope
> addition would be wrong. But if we are talking about "private", it's a
> different matter.
>
>
> I don't buy this argument. Before Swift, there have been plenty of OO
> languages with extensions and plenty with access control, but no major ones
> with both except Ruby (discounting Objective-C's @private instance
> variables). And, ignoring extensions, the behavior of 'private' in all of
> these languages is to include access from member types:
>
> - C++: yes
> - Java: yes
> - C#: yes
>
> - Ruby: no, but even the outer class can't invoke private methods on a
> different instance of itself
> - D: yes, but D's "private" is closer to Swift's current "private" than
> anything else
>
> - Kotlin: yes
> - Scala, Python, Go, Rust, Objective-C, Smalltalk: either no access
> control or no nested types, AFAICT
>
> So "private" in these languages doesn't seem to mean "restricted to this
> type", and that shouldn't be considered the "obvious" meaning when several
> of us have considered it decidedly non-obvious.
>
> Best,
> Jordan
>
> P.S. "If you move the type inside another type, the semantics is the
> same." This already isn't true if the new member type is used to satisfy a
> protocol requirement (which, because of retroactive modeling, counts as
> "changing the class's API"), but it especially won't be true if/when we
> start allowing member types inside generic types. In that case, the inner
> type now has extra generic parameterization that it wouldn't have had
> before.
>
> P.S. Extensions do make things a little more complicated, but again,
> there's almost no precedent here, and pretty much everyone agrees that this
> new scope-private access level shouldn't give access to extensions. That
> also means there's an option to keep yourself from accidentally accessing
> scope-private members in a member type: put the member type in an extension.
>
> _______________________________________________
> 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/20160330/b6b8c83a/attachment.html>