• What is your evaluation of the proposal? Against. • Is the problem being addressed significant enough to warrant a change to Swift? Problem is important enough. However my opinion is it is worth additional warnings not mandatory self.
• Does this proposal fit well with the feel and direction of Swift? I don't think adding so much visual noise to avoid name shadowing is a good thing. • How much effort did you put into your review? A glance, a quick reading, or an in-depth study? I have read some posts not all of course. • If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? 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. 2015-12-19 13:01 GMT+03:00 Tino Heth via swift-evolution <[email protected] <mailto:[email protected]>>: > • What is your evaluation of the proposal? -1 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. > • Is the problem being addressed significant enough to warrant a change > to Swift? I doubt that the proposal addresses any existing problem at all; it merely lessens issues due to unfortunate choice of names. > • Does this proposal fit well with the feel and direction of Swift? 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. As others have shown, clarity can be decreased by using the self prefix. > • How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? 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. 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. > What other solutions can we think up? 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. 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. Best regards, Tino _______________________________________________ swift-evolution mailing list [email protected] <mailto:[email protected]> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
