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

[Ilya Belenkiy]

The last sentence was meant to be:
Private and public have well defined meaning, we should keep the same
semantics.

Still, this is an edge case. Maybe we can separate it into another proposal.

On Thu, Mar 24, 2016 at 11:42 AM Ilya Belenkiy via swift-evolution <
swift-evolution at swift.org> wrote:

> This is why I'd like private to mean exactly that (no nested class should
> get access). Then the meaning is clear: it's as private as it can be :-)
>
> Private and public have well defined meaning. We
> On Thu, Mar 24, 2016 at 11:33 AM Ross O'Brien via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> I agree that 'private' still feels too subjective on its own. It's
>> intuitively 'not public'; it's not intuitively the access term for
>> 'declaration only'.
>>
>> I'm not opposed to fileprivate and moduleprivate, if we like those terms.
>> I'd just prefer a corresponding scopeprivate or declarationprivate.
>>
>> On Thu, Mar 24, 2016 at 3:21 PM, Brandon Knope via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>>
>>> > How about we continue this trend, and follow other existing Swift
>>> keywords that merge two lowercase words (associatedtype, typealias, etc),
>>> and use:
>>> >
>>> >    public
>>> >    moduleprivate
>>> >    fileprivate
>>> >    private
>>> >
>>> > The advantages, as I see them are:
>>> > 1) We keep public and private meaning the “right” and “obvious” things.
>>> > 2) The declmodifiers “read” correctly.
>>> > 3) The unusual ones (moduleprivate and fileprivate) don’t use the
>>> awkward parenthesized keyword approach.
>>> > 4) The unusual ones would be “googable”.
>>> > 5) Support for named submodules could be “dropped in” by putting the
>>> submodule name/path in parens: private(foo.bar.baz) or
>>> moduleprivate(foo.bar).  Putting an identifier in the parens is much more
>>> natural than putting keywords in parens.
>>> >
>>> > What do you all think?
>>> >
>>> > -Chris
>>> >
>>> >
>>> > _______________________________________________
>>> > swift-evolution mailing list
>>> > swift-evolution at swift.org
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> I'm not sure my wording will be perfect here, but I will try: I still
>>> believe that private is implied in "module" and "file" and the problem is
>>> in the name of the plain "private" keyword.
>>>
>>> You may say private is obvious, but when you have moduleprivate and
>>> fileprivate, the natural question I ask is "What remaining kind of private
>>> is there?" so private's obviousness is muddied for me when next to
>>> moduleprivate and fileprivate.
>>>
>>> I will say I would prefer these keywords to the proposed parameter
>>> keywords. I just think:
>>>
>>> file -> implies file only
>>> module -> implies module only
>>>
>>> where adding private to them only adds noise (I.e. fileprivate and
>>> moduleprivate)
>>>
>>> Brandon
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> 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/20160324/4b235153/attachment-0001.html>