<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="ltr" class=""><span style="font-size:12.8px" class="">• What is your evaluation of the proposal?</span><div class=""><span style="font-size:12.8px" class="">Against.</span></div><div class=""><span style="font-size:12.8px" class=""><br class=""></span></div><div class=""><span style="font-size:12.8px" class="">• Is the problem being addressed significant enough to warrant a change to Swift?</span><span style="font-size:12.8px" class=""><br class=""></span></div><div class=""><span style="font-size:12.8px" class="">Problem is important enough. </span><span style="font-size:12.8px" class="">However my opinion is it is worth additional warnings not mandatory self.</span></div><div class=""><span style="font-size:12.8px" class=""><br class=""></span></div><div class=""><span style="font-size:12.8px" class="">• Does this proposal fit well with the feel and direction of Swift?</span><span style="font-size:12.8px" class=""><br class=""></span></div><div class=""><span style="font-size:12.8px" class="">I don't think adding so much visual noise to avoid name shadowing is a good thing. </span></div><div class=""><span style="font-size:12.8px" class=""><br class=""></span></div><div class=""><span style="font-size:12.8px" class="">• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</span><span style="font-size:12.8px" class=""><br class=""></span></div><div class=""><span style="font-size:12.8px" class="">I have read some posts not all of course. </span></div><div class=""><span style="font-size:12.8px" class=""><br class=""></span></div><div class=""><span style="font-size:12.8px" class="">• </span><span style="font-size:12.8px" class="">If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</span><span style="font-size:12.8px" class=""><br class=""></span></div><div class=""><span style="font-size:12.8px" class="">The only language I have used where self is mandatory is Objective-C. I was never happy with this but it was justified by messaging idiom at least.</span></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">2015-12-19 13:01 GMT+03:00 Tino Heth via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> • What is your evaluation of the proposal?<br class="">
-1<br class="">
I like to use the self-prefix in many places, but there is no need to impose personal preferences on those with a different opinion.<br class="">
<br class="">
> • Is the problem being addressed significant enough to warrant a change to Swift?<br class="">
I doubt that the proposal addresses any existing problem at all; it merely lessens issues due to unfortunate choice of names.<br class="">
<br class="">
> • Does this proposal fit well with the feel and direction of Swift?<br class="">
When I look at the efforts that were taken to save type strokes when declaring a closure, and how the option of leaving out self is highlighted in the docs: I don't think so.<br class="">
As others have shown, clarity can be decreased by using the self prefix.<br class="">
<br class="">
> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class="">
I've read the whole discussion - although I think that "discussion" is a flattering expression, as I have to look really hard to find any examination of the valid counter arguments.<br class="">
Pondering over when to use self and when to skip it, I come to the conclusion that I have rules for this, but I would neither dictate those on others nor on the compiler.<br class="">
<span class=""><br class="">
> What other solutions can we think up?<br class="">
</span>1) Use the right tools - syntax coloring can ensure that you don't confuse members with other elements (please no "and what's with those that are color blind?"-arguments: There are other aspects of font that can be changed as well). It would also possible to automatically insert "self." if it is that important.<br class="">
2) Don't choose names that cause confusion in the first place… doing stupid things leads to stupid problems - but I have to admit that is possible to trip accidentally when choosing a name: For parent methods, this is solved with "override", for other identifiers, there could be warnings.<br class="">
<br class="">
Best regards,<br class="">
Tino<br class="">
<div class="HOEnZb"><div class="h5">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
</body></html>