Thank you Dave. I appreciate your thoughtful and complete response and will think further on this.
Daniel > On Apr 22, 2016, at 11:24 PM, Dave Abrahams via swift-evolution > <[email protected]> wrote: > > > > on Thu Apr 21 2016, Daniel Steinberg <[email protected]> wrote: > >> Pardon me if this has been raised before. >> >> I gave a short presentation at our Cleveland CocoaHeads this week on >> what is coming in Swift 3. One of the attendees stayed behind to ask >> about the naming guidelines for mutating vs non-mutating. He is fairly >> new to Swift - coming from Ruby. I have no Ruby experience but am >> passing his thoughts on to this list. >> >> He said that in Ruby they decorate the name with a symbol (I believe >> in their case it is “!”) to distinguish between the two. Although >> usually I’m not a fan of such naming conventions, we do something >> similar with inout parameters. >> >> For example, if we have >> >> func myFunc(param: inout String) { …} >> >> we call it like this (using the Swift 3 first label convention) >> >> myFunc(param: &aName) >> >> We use the & to signal that the value of aName might be changed by the call >> to myFunc(). >> >> Similarly, instead of settling on a naming convention for verb vs >> verbed/verbing we could name the methods descriptively and require a >> symbol (here I use & but only for illustration) to distinguish between >> mutating and non-mutating >> >> so we would have >> >> myArray.sort&() >> >> and >> >> sortedArray = myArray.sort() >> >> Xcode and other tools could enforce this naming pattern and warn us >> that a mutating method must end in “&” and that a non-mutating method >> is not allowed to. > > This is not a new idea. Something almost identical to this has been > explored and discussed quite thoroughly already: > <https://github.com/apple/swift/blob/master/docs/proposals/Inplace.rst>. > In fact, it was implmented and later reverted because it raised > language-design questions for which we had no good answers. I don't > believe the choice of glyph (& vs =) affects any of the fundamental > issues: > > * Should the x.=f() syntax be required for *every* mutating method > invocation? > > * Are assignment methods a redundant way to spell mutating methods? > Should we really have both mechanisms? > > * Can we really introduce this feature without having a way to apply it > to class types? > > I should also point out that under the assignment method paradigm one > would probably need to re-evalutate rules for naming. Under the current > API guidelines' approach, we'd write: > > x.=sorted() // sort x in-place > > and I am not sure how easy that would be for people to swallow > considering how much more straightforward > > x.sort() // current way to sort x in-place > > is, and because the language now contains explicit notation for > mutation, it becomes harder to argue against theis pair: > > y = x.sort() > x.=sort() // sort x in place > > Lastly, I should point out that the proposal does nothing to solve the > problem of `c.formSuccessor(&i)`, since that doesn't mutate the > receiver. > > I still like the proposal's basic approach and would love to see it used > to address these naming problems, but I want to be clear that it's by no > means a panacea and there are real obstacles between here and actually > being able to apply it. If you want to move forward with something like > this, you need to solve the problems described above. > > -- > Dave > > _______________________________________________ > 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
