[Opinion] Thoughts about the SE-0025 (Scoped Access Level) proposal

Hello.

I had a health problem and recently I needed a surgery because of it. Now
I'm fine (yay!), but I missed all the discussions and threads at this time.

Reading the SE-0025 proposal, which I find quite valid, I found it the
(ugly) keyword `fileprivate` and the lack of a `protected` scope. I know it
should be late for you to turn back, but below is my suggestion about the
access level scopes the Swift language could implement:

*public*
Nothing to change. Symbols will be visible to the CONTAINING TYPE and ALL
MODULES.

*protected **
Symbols visibility will be limited to the CONTAINING TYPE and DERIVED TYPES
from the containing type. (Rookies calling `myView.layoutSubviews()` no
more...)

*internal*
Nothing to change. Symbols will be visible to the CONTAINING TYPE and the
CURRENT MODULE.

*protected internal ****
Symbols visibility will be limited to the CONTAINING TYPE and DERIVED TYPES
from the containing type or the CURRENT MODULE. (They will be `protected`
when used by other modules, but `internal` when used by the current module.)

*private*
The symbols will be visible within the CONTAINING TYPE and the OTHER TYPES
in the SAME FILE. (This is the `fileprivate` proposed in SE-0025.)

*local ****
The symbols will be visible within the CONTAINING TYPE ONLY. (No other
types accessing my variables anymore... This is the proposed `private`in
SE-0025)

*The items marked with * denote new access levels. The other remain as they
are implemented in Swift 2.x*

Well... That was it.

Regards,

Vanderlei Martinelli

When you say you missed all the discussions and threads... you missed
probably the longest bikeshedding discussion we've had on Swift Evolution
so far.
First: no-one's ruled out a 'protected' access level yet. Equally, as far
as I recall, it hasn't been presented for review yet. It's neither accepted
nor rejected. How its type-based access nature works with Swift's
scope-based access system will be an interesting topic. Perhaps now's a
good time to start it.
Second: however ugly you find 'fileprivate', you understood what it meant.
Not knowing which of 'local' and 'private' was implicitly more private
drove a lot of that discussion; that's why 'fileprivate' won. It's also a
relative term - for example, since it would be pointless to declare a
protocol as 'local' in your hierarchy (since it would then be impossible
for another type to conform to it), the protocol would be declared as
'private' but would have 'fileprivate' visibility, which means you wouldn't
see 'fileprivate' perhaps as often as you're concerned about.

ยทยทยท

On Sun, May 8, 2016 at 9:13 PM, Vanderlei Martinelli via swift-evolution < swift-evolution@swift.org> wrote:

Hello.

I had a health problem and recently I needed a surgery because of it. Now
I'm fine (yay!), but I missed all the discussions and threads at this time.

Reading the SE-0025 proposal, which I find quite valid, I found it the
(ugly) keyword `fileprivate` and the lack of a `protected` scope. I know it
should be late for you to turn back, but below is my suggestion about the
access level scopes the Swift language could implement:

*public*
Nothing to change. Symbols will be visible to the CONTAINING TYPE and ALL
MODULES.

*protected **
Symbols visibility will be limited to the CONTAINING TYPE and DERIVED
TYPES from the containing type. (Rookies calling `myView.layoutSubviews()`
no more...)

*internal*
Nothing to change. Symbols will be visible to the CONTAINING TYPE and the
CURRENT MODULE.

*protected internal ****
Symbols visibility will be limited to the CONTAINING TYPE and DERIVED
TYPES from the containing type or the CURRENT MODULE. (They will be
`protected` when used by other modules, but `internal` when used by the
current module.)

*private*
The symbols will be visible within the CONTAINING TYPE and the OTHER TYPES
in the SAME FILE. (This is the `fileprivate` proposed in SE-0025.)

*local ****
The symbols will be visible within the CONTAINING TYPE ONLY. (No other
types accessing my variables anymore... This is the proposed `private`in
SE-0025)

*The items marked with * denote new access levels. The other remain as
they are implemented in Swift 2.x*

Well... That was it.

Regards,

Vanderlei Martinelli

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution