[swift-evolution] mutating/non-mutating suggestion from a Rubyist

[Dave Abrahams]

on Thu Apr 21 2016, Daniel Steinberg <swift-evolution at swift.org> 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