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

[Daniel Steinberg]

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 <swift-evolution at swift.org> wrote:
> 
> 
> 
> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution