> On Mar 24, 2016, at 9:59 AM, Ilya Belenkiy <[email protected]> wrote:
>
> I am not sure if consistency is a problem here. My primary concern is that as
> long as the class or extension code itself hasn't changed, it's private API
> stays hidden from anything else. If we can simply inject a class into a class
> or extension and get access to all of its internals, that reduces the
> protection level that private would provide. I'd like private to hide
> implementation details completely.
That wouldn’t be possible because the semantics are scope-based, not
type-based.
Here’s an example (using the new “private” modifier):
fileA.swift:
class C {
private let s: String
class Nested {
func foo() {
let c = C()
// s is visible here because `Nested` and `foo`
// are within the lexical scope that declared `s`
let s = c.s
}
}
}
extension C {
// `s` is not visible anywhere here
// because we are not within the lexical scope
// where `s` was declared
}
fileB.swift:
extension C {
// `s` is not visible anywhere here
// because we are not within the lexical scope
// where `s` was declared
}
>
> That said, I am not sure if we need to discuss it as part of this proposal.
> On Thu, Mar 24, 2016 at 10:28 AM Matthew Johnson <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> Sent from my iPad
>
> On Mar 24, 2016, at 8:40 AM, Ilya Belenkiy <[email protected]
> <mailto:[email protected]>> wrote:
>
>> The discussion was about the other direction: whether a nested class should
>> have access to private members of the outer class.
>
> In that case the answer seems clear as well. Everywhere in Swift's access
> model nested scopes have visibility to all members visible in the containing
> scope. For example, all scopes in a file can see any "fileprivate" members
> contained in that file.
>
> Following this semantic, all nested types would be able to see members of
> their containing type, even those with the new "private" visibility because
> the nested types are within the same scope where those members are declared.
>
> Semantic consistency is the most important concern IMO. All current access
> modifiers are strictly based on nested scopes. Hiding members of a
> containing type from a nested type would break this model and introduce
> type-driven semantics, which I think (and hope) is beyond the scope of this
> proposal (pun mildly intended).
>
> Matthew
>
>>
>> On Thu, Mar 24, 2016 at 9:35 AM Matthew Johnson <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>> Sent from my iPad
>>
>> On Mar 24, 2016, at 5:07 AM, Ilya Belenkiy via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>> It's very consistent with other keywords. I wish compound keywords were
>>> joined with a dash or something that made them easier to read, but I guess
>>> it's too late now. If we have associatedtype, it makes sense to use
>>> moduleprivate (I saw that the name associatedtype was discussed
>>> extensively but didn't participate in the discussion; I am sure that it was
>>> given a lot of thought). If we could change this, I'd suggest keyword names
>>> with dashes everywhere, but if not, these names work well and is a great
>>> compromise for everything I've seen in this thread.
>>>
>>> I am not worried about the length because the 2 most frequently written
>>> keywords would be public and private. Moduleprivate is the default, and
>>> file private will not be used as often as private.
>>>
>>> One question: should the proposal be explicit about access control for
>>> nested classes? We discussed it here briefly (I wanted private to be
>>> completely private to the class or extension itself while 2 other people
>>> wanted a nested class to have access to the outer class.)
>>
>> I don't think it would make sense at all to allow an outer type to see
>> private members of a nested class. That would break the semantics of
>> private meaning "containing scope".
>>
>> However, with Chris's suggestion of using identifiers as parameters, maybe
>> we could eventually have something like private(OuterTypeName) to specify
>> the precise level of access desired.
>>
>>>
>>> On Thu, Mar 24, 2016 at 1:13 AM Chris Lattner via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>> <responding to several posts in this thread at once>
>>>
>>> On Mar 14, 2016, at 5:18 PM, Chris Lattner via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>> > Per Doug’s email, the core team agrees we should make a change here, but
>>> > would like some bikeshedding to happen on the replacement name for
>>> > private.
>>>
>>> What we do with private setters is orthogonal from this proposal, so I’m
>>> going to ignore it in this thread. After SE-0025 is resolved, it would be
>>> great to have another thread/proposal that discusses reskinning
>>> private(set) - presumably as just a modifier on the setter.
>>>
>>> Similarly, this proposal has nothing to do with “protected” or any other
>>> type based access control, so I don’t delve into that at all either.
>>>
>>> I’ve seen several proposals that seem promising:
>>>
>>> On Mar 14, 2016, at 5:49 PM, James Berry <[email protected]
>>> <mailto:[email protected]>> wrote:
>>> > I like fileprivate, if that’s the only change. On the other hand, if we
>>> > want to consider a broader change, what about:
>>> >
>>> > private symbol visible within the current
>>> > declaration (class, extension, etc).
>>> > private(module) symbol visible within the current module.
>>> > private(file) symbol visible within the current file.
>>>
>>> I love how this establishes a family with different levels of access
>>> control, and unites them under the idea of "levels of being private”. I
>>> also like how people would commonly only ever write public and private
>>> (because “private(module)” is the default, and "private(file)" is obscure).
>>> However, parenthesized modifiers that take a keyword (as opposed to an
>>> identifier) are a bit weird and awkward, so it would be nice to avoid them
>>> if possible.
>>>
>>> On Mar 15, 2016, at 3:39 AM, Thorsten Seitz via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>> > public
>>> > private-module
>>> > private-file
>>> > private
>>>
>>> This follows the same sort of structure as James’ proposal, without the
>>> parens. It has the same advantages, but trades them with hyphenated decl
>>> modifiers. We don’t do that, but it is a good direction.
>>>
>>> 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
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
