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@swift.org wrote:
Re: Proposal: Re-instate mandatory self for accessing
instance properties and functions (David Hart)
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@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@swift.org wrote:
Re: Proposal: Re-instate mandatory self for accessing
instance properties and functions (David Hart)_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-1 from me on this one. I agree with Nick. IMO forcing self would
actually make the code less readable with a sea of Selfs all over the
place. `Self` blindness. This is not something that should be forced but
something that a linter should `enforce` per project or organization
depending on their style guide. If anything, I'd like a linter to tell me
when I am declaring self and self is not being captured.
On Sun, Dec 6, 2015 at 4:55 PM, Nick Shelley via swift-evolution < swift-evolution@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@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@swift.org wrote:
Re: Proposal: Re-instate mandatory self for accessing
instance properties and functions (David Hart)_______________________________________________
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
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@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@me.com <mailto:ycao@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@swift.org <mailto:swift-evolution-request@swift.org> wrote:
Re: Proposal: Re-instate mandatory self for accessing
instance properties and functions (David Hart)_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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
But swift is all about verbosity (with method naming and such brought from obj-c), having self is much clearer.
Yichen
On Dec 7, 2015, at 06:55, Nick Shelley <nickmshelley@gmail.com> 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@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@swift.org wrote:
Re: Proposal: Re-instate mandatory self for accessing
instance properties and functions (David Hart)_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Without commenting on the rest of the proposal, Swift is not about verbosity. From the API Design Guidelines <https://swift.org/documentation/api-design-guidelines.html#fundamentals> on Swift.org:
• Clarity at the point of use is your most important goal. Code is read far more than it is written.
• Clarity is more important than brevity. Although Swift code can be compact, it is a non-goal to enable the smallest possible code with the fewest characters. Brevity in Swift code, where it occurs, is a side-effect of the strong type system and features that naturally reduce boilerplate.
I'd say the same should apply to the language itself.
Jordan
On Dec 6, 2015, at 15:52, Yichen Cao via swift-evolution <swift-evolution@swift.org> wrote:
But swift is all about verbosity (with method naming and such brought from obj-c), having self is much clearer.
Yichen
On Dec 7, 2015, at 06:55, Nick Shelley <nickmshelley@gmail.com <mailto:nickmshelley@gmail.com>> 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@me.com <mailto:ycao@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@swift.org <mailto:swift-evolution-request@swift.org> wrote:
Re: Proposal: Re-instate mandatory self for accessing
instance properties and functions (David Hart)_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
David,
I disagree that your two examples don't tell us much.
foobar({
print(self.description)
})
This tells us that self will be captured by the closure, and reminds us
that if that might create a retain cycle, to avoid memory leaks we need to
add [weak self] or [unowned self] at the beginning of the closure.
barfoo({
print(description)
})
This tells us that we don't need to worry about self being captured in the
closure because the compiler would force us to add self if anything that
caused it to be captured were used in the closure.
This is very helpful information to me, and information that would stand
out less if I got used to seeing self everywhere, which is what your
proposal would force.
On Sun, Dec 6, 2015 at 6:10 PM, David Hart <david@hartbit.com> 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@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@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@swift.org wrote:
Re: Proposal: Re-instate mandatory self for accessing
instance properties and functions (David Hart)_______________________________________________
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
Method naming from Foundation, etc., should be getting amended:
Stephen
On Sun, Dec 6, 2015 at 6:52 PM, Yichen Cao via swift-evolution < swift-evolution@swift.org> wrote:
But swift is all about verbosity (with method naming and such brought from
obj-c), having self is much clearer.
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?
class HTMLElement {
let name: String
let text: String?
lazy var asHTML: Void -> String = {
if let text = unowned.text {
return "<\(weak.name)>\(text)</\(weak.name)>"
} else {
return "<\(unowned.name) />"
}
}
}
ABR.
On 7 Dec 2015, at 01:10, David Hart via swift-evolution <swift-evolution@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@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@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@swift.org wrote:
Re: Proposal: Re-instate mandatory self for accessing
instance properties and functions (David Hart)_______________________________________________
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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I strongly agree and that is why I quoted those two points in the proposal and why I believe that the proposal is beneficial: it brings clarity at the point of use.
On 07 Dec 2015, at 19:38, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
Without commenting on the rest of the proposal, Swift is not about verbosity. From the API Design Guidelines on Swift.org:
• Clarity at the point of use is your most important goal. Code is read far more than it is written.
• Clarity is more important than brevity. Although Swift code can be compact, it is a non-goal to enable the smallest possible code with the fewest characters. Brevity in Swift code, where it occurs, is a side-effect of the strong type system and features that naturally reduce boilerplate.
I'd say the same should apply to the language itself.
Jordan
On Dec 6, 2015, at 15:52, Yichen Cao via swift-evolution <swift-evolution@swift.org> wrote:
But swift is all about verbosity (with method naming and such brought from obj-c), having self is much clearer.
Yichen
On Dec 7, 2015, at 06:55, Nick Shelley <nickmshelley@gmail.com> 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@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@swift.org wrote:
Re: Proposal: Re-instate mandatory self for accessing
instance properties and functions (David Hart)_______________________________________________
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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
@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@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@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@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@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@swift.org wrote:
Re: Proposal: Re-instate mandatory self for accessing
instance properties and functions (David Hart)_______________________________________________
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_______________________________________________
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
I don’t agree with the premise that forcing `self` everywhere would improve clarity. I love it that lines like this:
buildSubviewInMode(mode).forEach(addSubview)
don’t look like this anymore:
self. buildSubviewInMode(self.mode).forEach(self.addSubview)
To me, the version without `self` is much clearer. Now of course people may disagree and that’s why a linter might enforce a coding style that requires self. But I don’t think the language itself should enforce that.
- Lukas
@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.
I think you misunderstood Andrew's point.
From what I understand, the main reason that self is required in closures
and not elsewhere is to serve as a compiler-enforced reminder about the
potential pitfalls of using self within closures (which I happen to think
it does well). Unless and until a different way of calling out those
pitfalls is proposed and accepted (as Andrew was suggesting), that point is
an essential part of the discussion IMO.
I don't think Andrew was suggesting that the discussion got sidetracked,
but realized that these two points can't be separated as the language
stands today, and was proposing a way to make them separate by
discontinuing the use of self as the way to call out capture semantics in
closures. At least that's what I understood when he said (regarding the use
of self in closures) "Perhaps if this could be modified *first* it would
help." (emphasis mine)
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
You forgot "Makes capture semantics of using self inside of closures less
apparent." I consider this the main con of the current proposal, and it
seems others do as well.
On Sun, Dec 13, 2015 at 8:55 PM, Dennis Lysenko via swift-evolution < swift-evolution@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" proliferationUnless 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@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@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@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@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@swift.org wrote:
Re: Proposal: Re-instate mandatory self for accessing
instance properties and functions (David Hart)_______________________________________________
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_______________________________________________
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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Nick, thanks for clarifying. Perhaps we could require an explicit [strong
self] in the cases where it is implicit, and Xcode autocomplete would
insert that any time it inserted a closure?
On Mon, Dec 14, 2015, 12:30 AM Nick Shelley <nickmshelley@gmail.com> 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.I think you misunderstood Andrew's point.
From what I understand, the main reason that self is required in closures
and not elsewhere is to serve as a compiler-enforced reminder about the
potential pitfalls of using self within closures (which I happen to think
it does well). Unless and until a different way of calling out those
pitfalls is proposed and accepted (as Andrew was suggesting), that point is
an essential part of the discussion IMO.I don't think Andrew was suggesting that the discussion got sidetracked,
but realized that these two points can't be separated as the language
stands today, and was proposing a way to make them separate by
discontinuing the use of self as the way to call out capture semantics in
closures. At least that's what I understood when he said (regarding the use
of self in closures) "Perhaps if this could be modified *first* it would
help." (emphasis mine)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" proliferationYou forgot "Makes capture semantics of using self inside of closures less
apparent." I consider this the main con of the current proposal, and it
seems others do as well.On Sun, Dec 13, 2015 at 8:55 PM, Dennis Lysenko via swift-evolution < > swift-evolution@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" proliferationUnless 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@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@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@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@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@swift.org wrote:
Re: Proposal: Re-instate mandatory self for accessing
instance properties and functions (David Hart)_______________________________________________
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_______________________________________________
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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
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@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" proliferationUnless 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@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?
class HTMLElement {
let name: String
let text: String?lazy var asHTML: Void -> String = {
if let text = unowned.text {
return "<\(weak.name)>\(text)</\(weak.name)>"
} else {
return "<\(unowned.name) />"
}
}
}ABR.
On 7 Dec 2015, at 01:10, David Hart via swift-evolution <swift-evolution@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@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@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@swift.org wrote:
Re: Proposal: Re-instate mandatory self for accessing
instance properties and functions (David Hart)_______________________________________________
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_______________________________________________
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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I agree, this change does not bring clarity. It just adds noise (`self.` everywhere) and removes the ability to use elided self as a reminder to watch out for retain cycles when creating escaping closures.
If you're teaching students and you're worried about mixing up local variables and properties, then feel free to always include the `self.` in your lessons. I don't see why the language has to change to enforce this one particular stylistic choice.
-Kevin Ballard
On Tue, Dec 8, 2015, at 04:56 PM, Lukas Stabe via swift-evolution wrote:
I don’t agree with the premise that forcing `self` everywhere would improve clarity. I love it that lines like this:
buildSubviewInMode(mode).forEach(addSubview)don’t look like this anymore:
self. buildSubviewInMode(self.mode).forEach(self.addSubview)
To me, the version without `self` is much clearer. Now of course people may disagree and that’s why a linter might enforce a coding style that requires self. But I don’t think the language itself should enforce that.
- Lukas
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
To expand, even on its own this could be beneficial in reminding
programmers of capture semantics in cases where they might forget, even
when they are experienced and aware of those semantics.
On Mon, Dec 14, 2015, 10:13 AM Dennis Lysenko <dennis.s.lysenko@gmail.com> wrote:
Nick, thanks for clarifying. Perhaps we could require an explicit [strong
self] in the cases where it is implicit, and Xcode autocomplete would
insert that any time it inserted a closure?On Mon, Dec 14, 2015, 12:30 AM Nick Shelley <nickmshelley@gmail.com> > 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.I think you misunderstood Andrew's point.
From what I understand, the main reason that self is required in closures
and not elsewhere is to serve as a compiler-enforced reminder about the
potential pitfalls of using self within closures (which I happen to think
it does well). Unless and until a different way of calling out those
pitfalls is proposed and accepted (as Andrew was suggesting), that point is
an essential part of the discussion IMO.I don't think Andrew was suggesting that the discussion got sidetracked,
but realized that these two points can't be separated as the language
stands today, and was proposing a way to make them separate by
discontinuing the use of self as the way to call out capture semantics in
closures. At least that's what I understood when he said (regarding the use
of self in closures) "Perhaps if this could be modified *first* it would
help." (emphasis mine)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" proliferationYou forgot "Makes capture semantics of using self inside of closures less
apparent." I consider this the main con of the current proposal, and it
seems others do as well.On Sun, Dec 13, 2015 at 8:55 PM, Dennis Lysenko via swift-evolution < >> swift-evolution@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" proliferationUnless 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@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@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@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@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@swift.org wrote:
Re: Proposal: Re-instate mandatory self for accessing
instance properties and functions (David Hart)_______________________________________________
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_______________________________________________
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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
@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@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@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" proliferationUnless 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@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@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@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@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@swift.org wrote:
Re: Proposal: Re-instate mandatory self for accessing
instance properties and functions (David Hart)_______________________________________________
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_______________________________________________
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_______________________________________________
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
This sounds like a candidate for a compiler option to add a warning (or error) if you leave out self. It adds no overhead to the language, but if you like it, you can enforce it.
-Kenny
Looks like the conversation is going in circles a bit. I believe Chris
Lattner said he was opposed to any compiler flags that would lead to
different dialects of Swift, and it's a valid concern, so I'm not sure how
feasible an optional compiler flag would be.
On Mon, Dec 14, 2015, 8:48 PM Kenny Leung via swift-evolution < swift-evolution@swift.org> wrote:
This sounds like a candidate for a compiler option to add a warning (or
error) if you leave out self. It adds no overhead to the language, but if
you like it, you can enforce it.-Kenny
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution