[swift-evolution] mutating/non-mutating suggestion from a Rubyist
Dave Abrahams
dabrahams at apple.com
Tue Apr 26 15:02:46 CDT 2016
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
> <swift-evolution at swift.org>:
>
> 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
> <swift-evolution at swift.org> 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
More information about the swift-evolution
mailing list