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

[Michael Peternell]

Isn't there a strong convention that overloaded methods should be very similar? Like a print function that takes a String and a print function that takes an Int? Having two 'sort' functions that are not even similar, but that just refer to the same concept ('sorting') seems confusing, and I haven't seen this in any other language so far. I think overloading is a somewhat advanced topic, and programming beginners should be allowed to be ignorant about this feature and just think "print is a function that prints its argument to the console" or "sort is a function that sorts a sequence" - not having to care if the function is overloaded or not. (I know that print() is not an overloaded function is Swift, this was just an example.)

-Michael

> Am 27.04.2016 um 23:13 schrieb Howard Lovatt via swift-evolution <swift-evolution at swift.org>:
> 
> 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> 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
> 
> 
> -- 
> -- Howard.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution