[swift-evolution] Proposal: Re-instate mandatory self for accessing instance properties and functions (David Hart)

Mon Dec 14 08:29:29 CST 2015

@Rudolf you could still have naming conflict in other locations than just
instance member access.

But safe refactoring is also possible without self. Eclipse for example
warns you when a name refactoring would lead to a naming conflict or
unexpected shadowing. The preview dialog then allows you to fix that case
before applying the new name.

On Mon, Dec 14, 2015 at 3:24 PM, Rudolf Adamkovic via swift-evolution <
swift-evolution at swift.org> wrote:

> Dennis, this one is missing on your "pros" list:
>
> • explicit "self" allows for safe refactoring
>
> See earlier discussion for more details and examples. It's something I
> stumbled upon multiple times.
>
> R+
>
> Sent from my iPhone
>
> On 14 Dec 2015, at 04:55, Dennis Lysenko via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> @Andrew: I agree that the discussion got a little sidetracked with people
> debating whether self should be required at all in closures. I personally
> think that your proposed solution may lead to needless ambiguity and
> confusion with regards to self-capture, and I would be careful with
> bringing it up as it could be a point of contention that may derail the
> discussion further. I personally don't agree with it but will reserve my
> judgment in the interest of staying on the topic of mandatory self.
>
> Could anyone provide a reasonably unbiased round-up of the pros/cons so
> far presented regarding required self capture?
>
> To start, on the pro side I have heard --
> - Differentiates locals and ivars, making code ostensibly more readable
> - Makes code more refactorable (proposed by me, counterargument: it may
> not be good to be able to move code around willy-nilly to and from closures
> when considering capture semantics)
>
> And on the con side, I have heard --
> - Annoying to do
> - Makes it harder to move from local to instance context
> - Makes code ostensibly less readable through "self" proliferation
>
> Unless I missed something (very possible seeing as I believe I've entered
> this discussion somewhat late), the rest seems to be anecdotal data and
> there does seem to be a solid split between the two schools.
>
> On Sun, Dec 13, 2015 at 5:14 PM Andrew Brown via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> I think the requirement to use self in closures complicates the
>> discussion.  Perhaps if this could be modified first it would help.
>> Perhaps instead of self to indicate capture, we should use
>> weak/strong/unowned etc as keywords to be explicit about the type of
>> capture.
>>
>> then the discussion on self wouldn't be side tracked with this?
>>
>>
>>    1. class HTMLElement {
>>    2.
>>    3.
>>    4.   let name: String
>>    5.   let text: String?
>>    6.
>>    7.
>>    8.   lazy var asHTML: Void -> String = {
>>    9.     if let text = unowned.text {
>>    10.       return "<\(weak.name)>\(text)</\(weak.name)>"
>>    11.     } else {
>>    12.       return "<\(unowned.name) />"
>>    13.     }
>>    14.   }
>>    15.
>>    16. }
>>
>>
>> ABR.
>>
>> On 7 Dec 2015, at 01:10, David Hart via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> Hi Nick,
>>
>> I understand the quote "This makes the capturing semantics of self stand
>> out more in closures”, but this is a very weak statement in Swift for me.
>> Let me try to explain.
>>
>> If we use the try keyword as an example:
>>
>> try foobar()
>> barfoo()
>>
>> If the previous lines of code compile without error, we know without a
>> shadow of a doubt that foobar is a throwing function and that barfoo
>> does not throw. The compiler will not compile the first line without the
>> keyword and would not allow it in on the second line.
>>
>> Now if we go back to the example of self in closures:
>>
>> foobar({
>> print(self.description)
>> })
>>
>> The self keyword in the previous lines of code does not tell us anything
>> at all:
>>
>>
>>    - self might have been forced by the compiler to warn us.
>>    - self might have been a programmer choice if the closure was
>>    non-escaping.
>>
>>
>> And the reverse:
>>
>> barfoo({
>> print(description)
>> })
>>
>> This also does not tell us much:
>>
>>
>>    - The closure might be non-escaping.
>>    - description might be referring to a local variable (which we missed
>>    the declaration) shadowing the instance property in an escaping closure.
>>
>>
>> In both of these last examples, we can’t tell by having a quick look at
>> the code at the point of call if we should really be careful about memory
>> or not.
>>
>> With the proposition, self gets some meaning back: it indicates which
>> are local and which are instance properties.
>>
>> David.
>>
>>
>> On 06 Dec 2015, at 23:55, Nick Shelley via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> I like that self is only required in closures because it serves as a good
>> reminder that there are memory and safety implications with using self in a
>> closure, such as creating retain cycles or having the closure run after
>> self has been deallocated.
>>
>> I can't seem to find an official Apple Swift style guide, but github's (
>> https://github.com/github/swift-style-guide) suggests only using self in
>> closures with the rationale: "This makes the capturing semantics of self
>> stand out more in closures, and avoids verbosity elsewhere."
>>
>> On Sat, Dec 5, 2015 at 3:16 AM, Yichen Cao <ycao at me.com> wrote:
>>
>>> Teaching wise, its much less confusing for self to be required so
>>> students don't mix up instance properties and local vars. Especially when
>>> self is required in closures, it confuses students. If self is mandatory
>>> for all instance properties, it would be so much clearer and much easier to
>>> read.
>>>
>>> Yichen
>>>
>>> On Dec 5, 2015, at 18:11, swift-evolution-request at swift.org wrote:
>>>
>>> Re: Proposal: Re-instate mandatory self for accessing
>>>      instance properties and functions (David Hart)
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> 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/20151214/ba6a9d1f/attachment.html>