on Tue Apr 26 2016, Thorsten Seitz <tseitz42-AT-icloud.com> wrote: > Am 23.04.2016 um 10:27 schrieb Pyry Jahkola via swift-evolution > <[email protected]>: > > I'd like to second James Campbell's suggestion of a `mutate` keyword. > Clarifying comments inline below: > > On 23 Apr 2016, at 00:24, Dave Abrahams via swift-evolution > <[email protected]> wrote: > > 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 know if the following are particularly good answers, but I'll try > anyway: > > 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? > > Allow me to ask it differently: Should some specific syntax be required > for > every mutating method? — Yes. > > I think I like that idea. > > Should the syntax be `x.=f()`? — Not necessarily. I kinda like James > Campbell's idea of a `mutate` keyword. Consider the following: > > var numbers = [5, 12, 6, 2] > mutate numbers.append(10) > mutate numbers.sort() > if let biggest = mutate numbers.popLast() { > print("The biggest number was:", biggest) > } > > So `mutate` would work much like `try` but—unlike `try` which can move > further to the left—`mutate` would have to always prefix the mutating > receiver. > > That doesn't look so bad (we might shorten 'mutate' to 'mut', though I don't > think that would be really necessary).
We've already discussed this whole question length, specifically considered the direction of an almost-identical language feature, and ended up settling on the “form/ed/ing” naming conventions. If there is some new information since then, it would be possible to handle something like this via a new evolution proposal. However, anything like that is way out of scope for Swift 3, and in the absence of new information, it isn’t a productive use of time to rehash it at all. -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
