[swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

Vladimir.S svabox at gmail.com
Tue Apr 11 17:39:16 CDT 2017


On 11.04.2017 19:47, Jose Cheyo Jimenez via swift-evolution wrote:
> 
>> On Apr 6, 2017, at 4:25 PM, Slava Pestov via swift-evolution 
>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>> Strong -1. This is a source breaking change, but Swift 4 stage 2 is already over.
> 
> I agree with you here. I don't think the proposal will be accepted as is, because of 
> the breaking change.
> 
> What if there was a way to make this a new feature so it is not a breaking change?
> 
> I can see this same proposal being accepted if it was revised to mark the new 
> extension behavior explicitly.

I like this idea, only extensions explicitly marked as "privileged" can have access 
to private members of the type.
But I suggest then go forward and do not use extension to access the private members 
but instead introduce new construction, which also can have stored properties and 
will have access modifier rules for types (not the rules for extensions). And such 
construction will be treated as continued declaration of the type itself. Only in the 
same file for now.

For example (just as idea for discussion) :

struct A {
   private var x = 0
}

continue A: P1 {
   private var y = 10
   func foo() {print(x + y)}
}

continue A: P2 {
   func bar() {print(x + y)}
}

Probably such type also should be marked somehow to be allowed to have continued 
definition, like

struct A split {
}

Later, when we'll have submodules, such 'continue' construction for the type should 
be allowed in other files of the same submodule and provide the flexible way to 
define the same type in a number of files.

> 
> *Type.swift*
> *
> *
> struct A {
> private func foo() {}
> }
> 
> *partial* extension A {  // any other keyword would do here or even \
> func baz() {
> foo()  // okay
> }
> }
> 
> extension A {
> func boo() {
> foo()  // error. Same as swift 3.
> }
> }
> 
> *Other.swift*
> *
> *
> *partial* extension A {  // error. Partial extensions only allowed within the 
> declaring file.
> }
> 
> extension A {
> func boo() {
> foo()  // error. Same as swift 3.
> }
> }
> 
> 
> 
>>
>> Slava
>>
>>> On Apr 6, 2017, at 4:10 PM, Douglas Gregor <dgregor at apple.com 
>>> <mailto:dgregor at apple.com>> wrote:
>>>
>>> Hello Swift community,
>>>
>>> The review of SE-0169 "Improve Interaction Between private Declarations and 
>>> Extensions" begins now and runs through April 11, 2017. The proposal is available 
>>> here:
>>>
>>>     https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>>>
>>> Reviews are an important part of the Swift evolution process. All reviews should 
>>> be sent to the swift-evolution mailing list at
>>>
>>>     https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager. When replying, please try to keep the proposal link at the top of the 
>>> message:
>>>
>>>     Proposal link:
>>>
>>>         https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>>>
>>>     Reply text
>>>
>>>         Other replies
>>>
>>>
>>>           <https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1>What
>>>           goes into a review?
>>>
>>> The goal of the review process is to improve the proposal under review through 
>>> constructive criticism and, eventually, determine the direction of Swift. When 
>>> writing your review, here are some questions you might want to answer in your review:
>>>
>>>   * What is your evaluation of the proposal?
>>>   * Is the problem being addressed significant enough to warrant a change to Swift?
>>>   * Does this proposal fit well with the feel and direction of Swift?
>>>   * If you have used other languages or libraries with a similar feature, how do
>>>     you feel that this proposal compares to those?
>>>   * How much effort did you put into your review? A glance, a quick reading, or an
>>>     in-depth study?
>>>
>>> More information about the Swift evolution process is available at
>>>
>>>     https://github.com/apple/swift-evolution/blob/master/process.md
>>>
>>> Thank you,
>>>
>>> -Doug
>>>
>>> Review Manager
>>>
>>> _______________________________________________
>>> swift-evolution-announce mailing list
>>> swift-evolution-announce at swift.org <mailto:swift-evolution-announce at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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
> 


More information about the swift-evolution mailing list