[swift-evolution] Enhancing access levels without breaking changes

Tue Apr 11 14:54:42 CDT 2017

Great, thanks for the clarification.
On Tue, Apr 11, 2017 at 14:50 John McCall <rjmccall at apple.com> wrote:

> On Apr 11, 2017, at 3:37 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
> SE-0169 is under active review, and is about expanding the meaning of
> scope to include extensions in the same file. The last day of the review
> period is today.
>
> What is this about yet another change?
>
>
> SE-0169 appears to say that extensions in the same file should not have
> access to each other's members if they are not in the same file as the type
> declaration.  Some reviewers have specifically objected to that clause as
> counter to the overall design of SE-0169.  Most reviewers appear to have
> overlooked it.  I have not seen any specific support for that clause that
> was not tied to overall disapproval of SE-0169.
>
> The Core Team often changes minor things like this by fiat after review;
> swift-evolution is not a legislative process where every last detail needs
> formal approval.  We'll have to talk about it if we decide to accept
> SE-0169.
>
> John.
>
> On Tue, Apr 11, 2017 at 14:31 David Hart via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> We’re not talking about the same proposal. I’m talking about SE-0169
>
> On 11 Apr 2017, at 19:49, Daniel Duan <daniel at duan.org> wrote:
>
> This never went into a review. The pull request is still open
> https://github.com/apple/swift-evolution/pull/587
>
> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I don't want to make any change until Chris has been able to chime in. If
> he agrees with us, what should be done?
>
> • Immediate change in the proposal?
> • Would it have to go through a new review?
> • Or can the Core Team make the change if it is accepted?
>
> On 11 Apr 2017, at 19:01, John McCall <rjmccall at apple.com> wrote:
>
>
> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
>
> On 11 Apr 2017, at 16:27, Matthew Johnson <matthew at anandabits.com> wrote:
>
>
>
> Sent from my iPad
>
> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On 11 Apr 2017, at 13:29, Jonathan Hull <jhull at gbis.com> wrote:
>
>
> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On 11 Apr 2017, at 09:40, John McCall <rjmccall at apple.com> wrote:
>
> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Sent from my iPhone
> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I have not voted in favor or against the proposal. I have been reading a
> lot of responses but I agree with Tony.
>
> When I started reading the proposal everything was more or less fine half
> way through the proposal because it was reverting private to fileprivate
> between the type and its extensions within the same file. I said, if you
> think of the type and its extensions as a unit then it makes sense. I can
> explain that.
>
> Then it started describing a different behavior among the extensions
> located in a file separate from the file containing the definition of the
> type. That just started a whole debate inside my head and I understand the
> passionate responses on both sides.
>
> But then I imagined myself explaining this to someone new to Swift and it
> just doesn't seem right. If it becomes convoluted then that's a red flag
> that it does not belong in Swift.
>
>
> I understand what you are saying and I wouldn't be against relaxing that
> requirement (not talking for Chris here).
>
> The model would change from "Types share scopes with their extensions in
> the same file the type was defined" to "Types and their extensions share
> the same scope in each file".
>
>
> Oh, I had missed that somehow.  I agree that that is a very strange rule.
> Do you know why it was proposed that way?
>
>
> We had to take a stance and Chris seemed to prefer the rule that was
> proposed. I didn't press because I'm sure he has reasons for preferring it
> that way. But I have a preference for generalizing visibility to all
> extensions, even to those in a different file than the type.
>
>
> I think there is a technical limitation if the visibility goes beyond the
> compilation unit (unless whole module optimization is turned on).
>
>
> I’m not suggesting visibility beyond the compilation unit. That would
> break the hierarchy of visibility layers: accessibility levels have always
> been contained in one-another and that’s why you can go from *private*, to
>  *fileprivate*, to *internal*, to *public*, to *open* (but not the other
> way round) without the risk of any compilation error. If all scopes of a
> type were visible to each other (whatever the file), you could not go from
>  *private* to *fileprivate*.
>
> I’m talking about extensions of the same type in the same file (but in a
> separate file from the type) to be able to share private members:
>
> *Type.swift*
>
> struct A {
> }
>
> *Other.swift*
>
> extension A {
>     func foo() {
>         bar()
>     }
> }
>
> extension A {
>     private func bar() {
>     }
> }
>
>
> If this is not how your proposal already works I missed that aspect
> earlier and find it extremely perplexing (which is probably why I missed
> it).
>
>
> It's mentioned in the Derailed design section:
>
> *This proposal does not change the behavior of extensions that are not in
> the same file as the type - i.e., extensions in a seperate file to the type
> do not share access between themselves:*
>
> But I agree this should be changed if there is no major technical reason
> against it.
>
>
> I'm not aware of any technical reason why extensions in the same file
> should not have access to each other's members.
>
> John.
>
>
> It leaves scoped access working as in Swift 3 in exactly the case where it
> is least useful.  We cannot place stored properties in any extensions, let
> alone extensions in a file other than the one containing the original
> declaration.
>
>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> 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/20170411/052ac18c/attachment.html>