[swift-evolution] [Review] Require self for accessing instance members

[Honza Dvorsky]

Many people (myself included) already expressed their preference in the
discussion that happened before the review, where there were many more
yes's. So for the sake of objectivity, I think we should refrain from
counting the score half way through the discussion :)

We all care about the outcome, but it was mentioned upstream that all
feedback (including pre-review) is being taken into consideration, which I
believe is fair.
On Thu, Dec 17, 2015 at 12:22 AM Stephen Celis via swift-evolution <
swift-evolution at swift.org> wrote:

> * What is your evaluation of the proposal?
>
> A strong -1. I understand the argument but believe it's a matter of style
> that should not be enforced by the compiler.
>
> * Is the problem being addressed significant enough to warrant a change to
> Swift?
>
> No. The few times implicit self has caused me to lose a few minutes
> troubleshooting would have been better addressed with improved diagnostics
> and error messaging (these few times were a result of me trying to be too
> clever). I agree with others that enforcing self is the job of a linter
> and/or in-house style guide.
>
> * Does this proposal fit well with the feel and direction of Swift?
>
> Overall no. I believe it reduces expressiveness (a major tenet according
> to https://swift.org/about/#swiftorg-and-open-source) and adds noise.
> While explicit self can add clarity at the point of use, I do not believe
> it's worth the noise and enforcing in all cases.
>
> * If you have you used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>
> I've written Ruby and Python extensively and value Ruby's expressive
> nature over Python's explicit proliferation of self.
>
> * How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
> I read the entire thread and participated throughout.
>
> At the time review began, I counted 5 explicit yeas and 12 explicit nays
> (as well as a few implicit nays).
>
> Stephen
>
> On Wed, Dec 16, 2015 at 5:54 PM, T.J. Usiyan via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> * What is your evaluation of the proposal?
>>     -1. I vote against this proposal. I believe that a linter and/or an
>> in house code guide is the best place to manage this.
>>
>> * Is the problem being addressed significant enough to warrant a change
>> to Swift?
>>     I think that it is a significant concern but, as I stated above, best
>> handled with tooling.
>> * Does this proposal fit well with the feel and direction of Swift?
>>     No. The current Swift behavior around this issue is clear and is
>> reasonable to many.
>> * How much effort did you put into your review? A glance, a quick
>> reading, or an in-depth study?
>>     I have followed the thread and have had this discussion many times.
>>
>> On Wed, Dec 16, 2015 at 5:47 PM, T.J. Usiyan <griotspeak at gmail.com>
>> wrote:
>>
>>> Creating that summary seems like it would be a large burden to place on
>>> whoever manages the review. I don't think that that is worth the effort
>>> when the responses *are* readily available.
>>>
>>> On Wed, Dec 16, 2015 at 3:09 PM, Nick Shelley via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>>> All of the prior swift-evolution commentary on this proposal (which is
>>>>> nearing the 100-message mark) will also be considered, of course!
>>>>
>>>>
>>>> It is my opinion that the proposal should encapsulate as much of that
>>>> discussion as possible so every reviewer doesn't have to read every comment
>>>> in that thread. The current proposal is wildly one-sided and seems to only
>>>> reflect the opinion of its author and those who agree with the proposal. I
>>>> created a Pull Request (
>>>> https://github.com/apple/swift-evolution/pull/59, still not merged and
>>>> no comments as to why) to more fairly represent the single counter-argument
>>>> pointed out in the proposal, but others in the mailing list expressed
>>>> concern that none of the other downsides of the proposal are represented at
>>>> all.
>>>>
>>>> Is my (and others') desire to have the proposal contain an accurate
>>>> representation of the main points of the community discussion off base? Is
>>>> the main purpose of the proposal to be a sales pitch for an idea, even if
>>>> it includes building up and tearing down straw-man versions of the
>>>> arguments brought forth by the opposition? I'm asking with sincere
>>>> curiosity because I can't seem to find a good description of the purpose of
>>>> the proposal in my research of how the evolution process works.
>>>>
>>>> Thanks in advance for clarifying these points for me.
>>>>
>>>> On Wed, Dec 16, 2015 at 11:58 AM, Douglas Gregor via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>>
>>>>> All of the prior swift-evolution commentary on this proposal (which is
>>>>> nearing the 100-message mark) will also be considered, of course!
>>>>>
>>>>> - Doug
>>>>>
>>>>> On Dec 16, 2015, at 10:55 AM, Douglas Gregor via swift-evolution <
>>>>> swift-evolution at swift.org> wrote:
>>>>>
>>>>> Hello Swift community,
>>>>>
>>>>> The review of “Require self for accessing instance members” begins now
>>>>> and runs through Sunday, December 20th. The proposal is available here:
>>>>>
>>>>>
>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.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.
>>>>>
>>>>> 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 you 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
>>>>>
>>>>> Cheers,
>>>>> Doug Gregor
>>>>> Review Manager
>>>>> _______________________________________________
>>>>> 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/20151216/7285b38b/attachment.html>