1

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" :-)

-Thorsten

···

Am 26. April 2016 um 22:02 schrieb Dave Abrahams dabrahams@apple.com:

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>.
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).

on Tue Apr 26 2016, Thorsten Seitz <tseitz42-AT-icloud.com> wrote:

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

2

I'd like to second James Campbell's suggestion of a `mutate` keyword.
Clarifying comments inline below:

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;\.
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.

···

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> wrote:
Am 23.04.2016 um 10:27 schrieb Pyry Jahkola via swift-evolution >>> <swift-evolution@swift.org>:
On 23 Apr 2016, at 00:24, Dave Abrahams via swift-evolution >>> <swift-evolution@swift.org> wrote:

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

3

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> wrote:

Sent from my iPad

On Apr 27, 2016, at 12:37 AM, Thorsten Seitz via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

Am 26. April 2016 um 22:02 schrieb Dave Abrahams <dabrahams@apple.com
<javascript:_e(%7B%7D,'cvml','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
<javascript:_e(%7B%7D,'cvml','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 > <javascript:_e(%7B%7D,'cvml','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;\.

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
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.

4

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@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@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> 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;\.
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

5

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

6

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@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@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@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> 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;\.
>>>> 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