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

[Radosław Pietruszewski]

Q: Would it be possible to allow some sigil in method names (say, prefix/postfix `=`) without any automatic/magic treatment of these methods?

In Ruby, after all, postfix `!` is just allowed in names. It doesn’t have any semantic meaning for the interpreter, it’s just the (strong, well agreed upon) convention to use it to mark mutating methods in mutating/non-mutating pairs, like `foo.map(…)` vs `foo.map!(…)`.

It works out well for Ruby. Would it be out of question to allow the same thing in Swift? A naming convention (`foo.sort()` vs `foo.sort=()`), not an automatic language feature?

— Radek

> On 22 Apr 2016, at 23:24, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
> on Thu Apr 21 2016, Daniel Steinberg <swift-evolution at swift.org <mailto: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 <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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160425/c64c7a30/attachment.html>