mutating/non-mutating suggestion from a Rubyist

[James_F]

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@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@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

   Sent from my iPad

   On Apr 27, 2016, at 12:37 AM, Thorsten Seitz via swift-evolution > <swift-evolution@swift.org> wrote:

   Am 26. April 2016 um 22:02 schrieb Dave Abrahams <dabrahams@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@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@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&gt;
   <https://github.com/apple/swift/blob/master/docs/proposals/Inplace.rst>&gt;\.
   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@swift.org
   https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
‰í

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

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

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

From James F