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

[Howard Lovatt]

Think of the name of the mutating method sort as `mutating sort`, i.e. a
different name than `sort` and therefore not an overload. This way the call
and declaration match:

    struct Array<T>: ... {
        func mutating sort(...) { ... }
        func sort(...) -> [T] { ... }
    }

    mutating array.sort(>)
    let sorted = array.sort(>)

As a critique of the `func mutating <name>` proposal consider:

    protocol P {
        func mutating p()
        func p()
    }

    class AP: P {
        func mutating p() { ... } // `mutating` not currently allowed in a
class
        func p() { ... }
    }

    let aP = AP()
    mutating aP.p() // Odd since `aP` is a let - but would everyone get
used to it quickly and realize that what `aP` points to is mutated


  -- Howard.

On 28 April 2016 at 07:50, Michael Peternell <michael.peternell at gmx.at>
wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160428/94706903/attachment.html>