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

[Matthew Johnson]

Sent from my iPad

> On Apr 27, 2016, at 12:37 AM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> Am 26. April 2016 um 22:02 schrieb Dave Abrahams <dabrahams at apple.com>:
>> 
>> 
>>> 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
> 
> 
> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160427/66c825ae/attachment.html>