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

[Howard Lovatt]

Personally I like the xxx and xxxed naming, e.g. sort and sorted, and think
it should be universally applied, e.g. union and unioned.

However that proved unpopular and we ended up with a hybrid with sort and
sorted but union and formUnion. Which no one seems to like!

Therefore I suggest a new review for the proposed:

    mutating array.sort(<)
    let sorted = array.sort(<)
    mutating set.union(other)
    let unioned = set.union(other)

I think the motivation for new review, or new information if you like, is
the discussion didn't cease after the decision was taken, unlike most
discussions on swift-evolution.

On Wednesday, 27 April 2016, Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> Sent from my iPad
>
> On Apr 27, 2016, at 12:37 AM, Thorsten Seitz via swift-evolution <
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>
> Am 26. April 2016 um 22:02 schrieb Dave Abrahams <dabrahams at apple.com
> <javascript:_e(%7B%7D,'cvml','dabrahams at apple.com');>>:
>
>
> on Tue Apr 26 2016, Thorsten Seitz <tseitz42-AT-icloud.com
> <http://tseitz42-at-icloud.com>> wrote:
>
> Am 23.04.2016 um 10:27 schrieb Pyry Jahkola via swift-evolution
>
> <swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>

-- 
-- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160428/c5665b76/attachment.html>