Sent from my iPad
> On Apr 27, 2016, at 12:37 AM, Thorsten Seitz via swift-evolution > <[email protected]> wrote: > >> Am 26. April 2016 um 22:02 schrieb Dave Abrahams <[email protected]>: >> >> >>> 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 > > > The new information might be that the "form" naming conventions have not been > that well received, i.e. the naming discussion cannot really be described as > "settled" :-) Also, I could be wrong but IIRC the discussion of having some kind of "mutation" syntax post Swift 3 was held open when that discussion concluded. It was just out of scope for Swift 3 to address all of the necessary issues. I hope this issue isn't settled once and for all as I am not very happy with the current solution. The "form" names are quite awkward and confusing IMO. I would eventually get used to them but that is the problem - they will really take getting used to. > > -Thorsten > _______________________________________________ > 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
