I think most of what has been said in favor of explicit `self` is valid to some degree, however I think it is a matter of _code style_ that should be considered by each team. If there is indeed a clear benefit in using it, it will certainly become idiomatic over time. Personally, I think this is some verbosity that we can live without.
Francisco On Fri, Dec 18, 2015 at 12:33 AM, David Hart via swift-evolution < [email protected]> wrote: > Hi people, > > I've tried to avoid interacting with the discussions here and on Twitter > because all the good arguments on both sides of the fence seem to have been > given and that it would just add more fuel to what seems like a pretty hot > fire :) > > But I'd like to move the discussion forward. I've I'd have to summarize > all of it, it seems like they are people who like the implicitness of self > and REALLY don't like my proposal, because it would induce a heavy writing > and reading cost to code which looks fine to them. > > On the other hand, there are people like me who already use self > explicitly to help document the scope of variables used and where there > might be hidden side effects of getters and setters, and really appreciate > he advantages it brings. It seems that we would enjoy a language that > forces explicitness to be able to read code everywhere and be able to make > the same assumptions. > > But it seems that we all agree with the underlying issue: that the fact > that the neither the language, nor the code conventions, nor the compiler > makes it extremely clear about the scope of variables at the point of use > as other languages might (Ruby comes to mind). > > We just seem to disagree on explicit self being the solution: it adds a > lot of verbosity for people who prefer succinctness (even if I think it is > a less important goal). > > What other solutions can we think up? We already discussed using other > prefix keywords which are less verbose than self, but couldn't come up with > any great solution. I would just like the language help us here to make > things safer without everybody using their own naming conventions or > Hungarian notation. > > David > > PS: I haven't found time to update the proposal and I'd like to apologize > if it sounded a bit too much one sided - I wrote it before a lot off e nag > give feedback, and tried to stick to the style of other proposals, but > perhaps failed in doing so. > > > On 17 Dec 2015, at 23:38, Rudolf Adamkovic via swift-evolution < > [email protected]> wrote: > > After careful reading through all the arguments, I'm now in the -1 camp > too. > > The "visual noise" examples and reasoning about consistency with the rest > of the language totally got me. > > P.S. I really liked the idea to use a dot instead of dot self but yeah, > dot is already reserved for enums. > > R+ > > Sent from my iPhone > > On 16 Dec 2015, at 19:55, Douglas Gregor via swift-evolution < > [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
