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
<[email protected] <mailto:[email protected]>> wrote:
Sent from my iPad
On Apr 27, 2016, at 12:37 AM, Thorsten Seitz via swift-evolution
<[email protected]> wrote:
Am 26. April 2016 um 22:02 schrieb Dave Abrahams <[email protected]>:
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
<[email protected]>:
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
<[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
--
-- Howard.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
