> On Jun 28, 2016, at 22:16, Matthew Johnson <matt...@anandabits.com> wrote:
>
>
>>> On Jun 28, 2016, at 9:06 PM, Jordan Rose via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>>
>>>
>>> On Jun 28, 2016, at 19:03, Matthew Judge <matthew.ju...@gmail.com> wrote:
>>>
>>> Comments inline.
>>>
>>>> On Jun 28, 2016, at 04:14, David Hart via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>>
>>>> Hello everybody,
>>>>
>>>> I tried using the access rules defined in SE-0025 in some code of mine to
>>>> see what effect it would have. I came out of the experiment more
>>>> disappointed than I thought. Here are several reasons:
>>>>
>>>> 1) The new rules make `private` more prominent compared to `fileprivate`
>>>> (the latter has a somewhat worse name). But at the same time, the Swift
>>>> community has developed a style of coding where a type is defined through
>>>> a set of extensions. To hide members from other types, but have access to
>>>> them inside the type extensions, we have often used `private` and placed
>>>> the type and its extensions in the same file. Because `private` is scoped,
>>>> we are forced into using `fileprivate` pervasively (which is uglier),
>>>> using `internal` instead (which is less safe) or moving the extension code
>>>> into the type's scope (which is against the way Swift code is being
>>>> written today). All of these options look worse to be than before SE-0025.
>>>
>>> If I understand SE-0025 (even with the amendment) you can still spell the
>>> access modifier to types as 'private' and get the same characteristics as
>>> the pre-SE-0025 meaning or private, so I'm not sure I understand the
>>> concern here. However (continued below)
>>>>
>>>> 2) The new amended rules look complicated to me. I think they have the
>>>> risk of being confusing in practice, but we’ll have to see.
>>>>
>>>
>>> I definitely agree that the amended rules look complicated. It seems to me
>>> that the amended set of rules is favoring simplifying the implementation
>>> over simplifying the mental model.
>>>
>>> My impression of what SE-0025 decided was that 'private' meant private to
>>> the enclosing scope. If the access modifying 'private' was applied to a
>>> type at the file scope, then it was synonymous with fileprivate and the
>>> default access of members of that type should be fileprivate.
>>>
>>> If a inner type was declared private, than the default access of members of
>>> that inner type should be private to the Outer type, not fileprivate. There
>>> is currently no way of expressing this access explicitly, but it does not
>>> seem like an especially useful thing to need to spell.
>>>
>>> Said in code, my impression of SE-0025 is that
>>>
>>> private class Outer { // exactly equivalent to fileprivate
>>> var myVar = 0 // default: fileprivate
>>> private class Inner { // private to Outer
>>> var hiddenVar = 0 // default: private to Outer
>>> private var reallyHiddenVar = 0 // default private to Inner
>>> }
>>> }
>>
>> This is definitely one of the considered alternatives. Both Brent and I
>> didn’t like the idea of an access level that you couldn’t actually spell,
>> and even if we got past that, we’d still need a way to refer to it in
>> documentation and diagnostics. I would count that as a larger change than
>> just allowing ‘fileprivate’ in places that previously would have been called
>> redundant.
>
> This was really the fact that didn’t receive adequate attention during
> discussion and review - that the semantics everyone understood it to have
> implied visibility for members that you cannot state explicitly. It didn’t
> bother me initially, but the diagnostics point Jordan makes is pretty
> important (I think we could handle it ok in documentation). Good diagnostics
> are extremely important and they must be both clear and concise. In order to
> have good diagnostics we need a name for the visibility that everyone knows
> so it may as well be part of the language.
>
I don't want to reopen the bike shedding, but this issue was one of the main
reasons I was in favor of the 'private(file)' spelling. 'private(Outer)',
'private(Inner)', etc. fall out as fairly obvious spellings for these cases in
my mind. (The only big negative I see to those spellings is the potential for
confusion for anyone too used to type-based access modifiers: that something
marked 'private(Outer)' would not be visible in 'extension Outer {}')
>>
>> Jordan
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
