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

[James Froggatt]

To clarify, I would expect mutating on classes to mean:

let ref = Class()
ref.mutate() //error: change let to var to allow mutation

Similar to how it works for value types, except here what gets mutated is the reference, not the value.

------------ Begin Message ------------ 
Group: gmane.comp.lang.swift.evolution 
MsgID: <B9515755-EDCC-4FF0-AD7B-CA1C06D0E1BA at ntlworld.com> 

The mutating keyword as it exists now actually has a meaning to classes. If one declares a protocol with a mutating function, then implements it with a protocol extension, any conforming classes can gain the mutating function, allowing ‘self’, the pointer, to be reassigned.

I think this is a bug, but this is also what I would expect ‘mutating’ to mean for reference types.

------------ Begin Message ------------ 
Group: gmane.comp.lang.swift.evolution 
MsgID: <f2e98910-c625-55b1-e608-67be93888bdc at gmail.com> 

Choosing between sort/sorted/union/formUnion(but map/filter/reduce) and 
explicit 'mutating' keyword - I'll choose the later.
(But I prefer marker like array&.sort(<) for mutating methods)

But I feel like this discussion(regarding naming) is closed and decision is 
made, and we can just exchange opinions on that decision. And it seems like 
the most of us agree with the decision. So...

On 28.04.2016 0:13, Howard Lovatt via swift-evolution wrote:
> 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 <mailto: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> 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
>>>    <http://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>
>>>>    <https://github.com/apple/swift/blob/master/docs/proposals/Inplace.rst%3E>.
>>>>    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
>
>
>
> --
> -- Howard.
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
‰í

------------- End Message ------------- 



From James F
_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
`9

------------- End Message ------------- 



From James F