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

[Dany St-Amant via swift-evolution]

> Le 28 avr. 2016 à 03:34, Pyry Jahkola via swift-evolution 
>  a écrit :
> 
> Good that you brought the topic of "fluent" interfaces up. I don't see any 
> problem with explicit value type mutation and method chaining because fluent 
> interfaces are constrained to reference types by the language. Details below:
> 
>> On 28 Apr 2016, at 03:44, Tyler Cloutier  wrote:
>> 
>> How would this chain if I wanted to do something like:
>> 
>> let median = foo.calculateBigHugeArray().sort().medianValue()
>> 
>> and I want the sort to be done in place.
> 
> I think I can guess what you wanted the above to mean but, mind you, the 
> in-place sort returns `()` so you wouldn't chain its result like that. On the 
> other hand, the above code already works using the non-mutating `.sort()` (to 
> be known as `.sorted()` in Swift 3), and—correct me if I'm wrong—the compiler 
> probably optimises the copy away using copy-on-write anyway.
> 
>> Or will this type of thing just be disallowed in favor of.
>> 
>> let array = foo.calculateBigHugeArray()
>> mutate array.sort()
>> let median = array.medianValue() 
> 
> Yes, I think mutating code should be written in many statements rather than 
> squeezing everything into one long expression.
> 
> Indeed, no currently working method chaining would be disallowed in my 
> proposal. Let's consider the example of "fluent API" for value types, i.e. 
> one where you'd extensively `return self` in `mutating` methods. Firstly, the 
> stdlib doesn't practice that at all. And I failed to find any popular Swift 
> libraries that would do so on Github either. The reason is simple: fluent 
> mutating APIs on value types don't work.
> 
> Consider the following silly example that shortens an array in half (but 
> demonstrates the use of `return self` in a `mutating` method):
> 
> extension Array {
> mutating func halve() -> Array {
> self = self[0 ..< count / 2]
> return self
> }
> }
> 
> Suppose I want to get the result of halving an array twice. What happens?
> 
> var xs = [1,2,3,4,5,6,7,8]
> xs.halve().halve()
> // error: cannot use mutating member on immutable value: function call 
> returns immutable value
> 
> So no, fluent APIs on value types are not a thing in Swift. Not now at least. 
> Making mutation explicit along this proposal has nothing to do with fluent 
> APIs.

But is this limitation as per design, or just something that no one reported as 
a bug yet? When acting on large piece of data and simple operations one might 
want to chain mutable version (to avoid large allocation) of the operations as 
a single stream (à la functional programming)  instead of having to use 
multiple line of:
  mutate largeData.operation()

On a side note, this "long" explicit 'mutate' keyword could be seen by some as 
a way to impose the use immutability by making it harder (more to type) to use 
mutability.

Also, this 'mutate' could maybe help to differentiate between sort() 2.2-style 
and sort() 3.0-style, and avoid endless discussion on InPlace/form/ed/ing. But 
for language uniformity, would this new 'mutate' keyword be required on nearly 
every single standard OOP methods?

mutate graph.pencil.changeColor(Red) // the color properties of pencil is 
mutated
mutate graph.pencil.changeWidth(wide)
mutate graph.drawFrame() // the graphic is altered/mutated

Not proposing, just asking.

Dany

> 
>> Alternately you could replace the method invocation operator with &
>> 
>> let median = foo.calculateBigHugeArray()().medianValue()
> 
> Don't you think that's too prone to getting mixed up with the binary `&` 
> operator?
> 
>> Also, if you wanted to stick with consistent & syntax, you could do:
>> 
>> (i)
>> and 
>> let k = ()
> 
> 
> Yeah, probably. However, one place where that notation falls short compared 
> to a prefixing keyword like `mutate` is when mutating `self`:
> 
> extension Array {
> // Apologies for not having the time to think of a less contrived 
> example than this!
> mutating func quarter() {
> mutate self.halve() // Ever since SE-0009, it's unusual to use 
> `self` here.
> mutate halve()  // Where would you put the `&` prefix in this?
> }
> }
> 
> — Pyry
> 
> ___
> 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

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

[Dave Abrahams via swift-evolution]

on Thu Apr 28 2016, "pyry.jahkola--- via swift-evolution" 
 wrote:

> On 28 Apr 2016, Dave Abrahams wrote:
>
> I think I can guess what you wanted the above to mean but, mind you, 
> the
> in-place sort returns `()` so you wouldn't chain its result like that.
> On the
> other hand, the above code already works using the non-mutating 
> `.sort()
> ` (to be
> known as `.sorted()` in Swift 3), and—correct me if I'm wrong—the
> compiler
> probably optimises the copy away using copy-on-write anyway.
>
> No, the compiler can't automatically turn non-mutating operations into
> in-place operations.
>
> I'm talking about `.sorted()` in particular. Its implementation is essentially
> this:
>
> var result = ContiguousArray(self) // What if `self` is not used after this
> line?
> result.sort()
> return Array(result)
>
> Depending on what `self ` is and how copy-on-write works, if `foo().sorted()`
> was called on a temporary (unique) Array returned by `foo()`, I believe the
> initialisation `ContiguousArray(self)` could be able to reuse `self._buffer`
> instead of making a copy. 

Yes, *if* `self` was a contiguous array, there will be no copy in that
line, and *if* ARC can determine that `self` is not used after `result`
is constructed, then `result` will have a unique reference to the same
buffer and `result.sort()` can avoid doing a copy before mutating the
result.

> Whether it indeed does that, remains unclear to me, probably not.

It's worth doing an experiment; it might well work.  And if it doesn't,
someone should file a bug report :-)

-- 
Dave

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

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

[pyry.jahkola--- via swift-evolution]

> On 28 Apr 2016, Dave Abrahams wrote:
> 
>> I think I can guess what you wanted the above to mean but, mind you, the
>> in-place sort returns `()` so you wouldn't chain its result like that. On the
>> other hand, the above code already works using the non-mutating `.sort()` 
>> (to be
>> known as `.sorted()` in Swift 3), and—correct me if I'm wrong—the compiler
>> probably optimises the copy away using copy-on-write anyway.
> 
> No, the compiler can't automatically turn non-mutating operations into
> in-place operations.

I'm talking about `.sorted()` in particular. Its implementation 

 is essentially this:

var result = ContiguousArray(self) // What if `self` is not used after this 
line?
result.sort()
return Array(result)

Depending on what `self ` is and how copy-on-write works, if `foo().sorted()` 
was called on a temporary (unique) Array returned by `foo()`, I believe the 
initialisation `ContiguousArray(self)` could be able to reuse `self._buffer` 
instead of making a copy. Whether it indeed does that, remains unclear to me, 
probably not 
.

— Pyry

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

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

[Dave Abrahams via swift-evolution]

on Thu Apr 28 2016, Pyry Jahkola  wrote:

> Good that you brought the topic of "fluent" interfaces up. I don't see any
> problem with explicit value type mutation and method chaining because fluent
> interfaces are constrained to reference types by the language. Details below:
>
> On 28 Apr 2016, at 03:44, Tyler Cloutier
>  wrote:
>
> How would this chain if I wanted to do something like:
>
> let median = foo.calculateBigHugeArray().sort().medianValue()
>
> and I want the sort to be done in place.
>
> I think I can guess what you wanted the above to mean but, mind you, the
> in-place sort returns `()` so you wouldn't chain its result like that. On the
> other hand, the above code already works using the non-mutating `.sort()` (to 
> be
> known as `.sorted()` in Swift 3), and—correct me if I'm wrong—the compiler
> probably optimises the copy away using copy-on-write anyway.

No, the compiler can't automatically turn non-mutating operations into
in-place operations.

-- 
Dave

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

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

[James Froggatt via swift-evolution]

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:  

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:  

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
> > wrote:
>
>
>
>Sent from my iPad
>
>On Apr 27, 2016, at 12:37 AM, Thorsten Seitz via swift-evolution
> wrote:
>
>>Am 26. April 2016 um 22:02 schrieb Dave Abrahams :
>>
>>>
>>>on Tue Apr 26 2016, Thorsten Seitz >>> wrote:
>>>
Am 23.04.2016 um 10:27 schrieb Pyry Jahkola via swift-evolution
:

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

This is not a new idea. Something almost identical to this has been
explored and discussed quite thoroughly already:


 .
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 

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

[Vladimir.S via swift-evolution]

On 28.04.2016 10:34, Pyry Jahkola via swift-evolution wrote:


*extension* Array {
// Apologies for not having the time to think of a less contrived
example than this!
*mutating* *func* quarter() {
*mutate* *self*.halve() // Ever since SE-0009
,
it's unusual to use `self` here.
*mutate*halve()  // Where would you put the `&` prefix in this?
}
}


How about '&' as allowed prefix/suffix for method name as a marker of 
mutating method? I.e.


self.()
()

or

self.halve&()
halve&()


Actually, IMO () is not a variant as it probably could be used in 
function like


something(  )  - confused

so, the suggestion is to have '&' suffix as marker of mutating methid:

self.halve&()
halve&()


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

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

[James Froggatt via swift-evolution]

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:  

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
> > wrote:
>
>
>
>Sent from my iPad
>
>On Apr 27, 2016, at 12:37 AM, Thorsten Seitz via swift-evolution
> wrote:
>
>>Am 26. April 2016 um 22:02 schrieb Dave Abrahams :
>>
>>>
>>>on Tue Apr 26 2016, Thorsten Seitz >>> wrote:
>>>
Am 23.04.2016 um 10:27 schrieb Pyry Jahkola via swift-evolution
:

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

This is not a new idea. Something almost identical to this has been
explored and discussed quite thoroughly already:


 .
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 

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

[Pyry Jahkola via swift-evolution]

> On 28 Apr 2016, at 10:59, Tyler Fleming Cloutier  
> wrote:
> 
> Yup, that pretty much addresses all of my concerns. So count me amongst the 
> fans. 

By the way,

I can be counted as +1 on reusing the keyword `mutating` here.

However, for the reasons stated in my previous email, I maintain that the 
keyword should go before the value being mutated rather than next to the 
function's name.

— Pyry

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

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

[Tyler Fleming Cloutier via swift-evolution]

> On Apr 28, 2016, at 12:34 AM, Pyry Jahkola  wrote:
> 
> Good that you brought the topic of "fluent" interfaces up. I don't see any 
> problem with explicit value type mutation and method chaining because fluent 
> interfaces are constrained to reference types by the language. Details below:
> 
>> On 28 Apr 2016, at 03:44, Tyler Cloutier > > wrote:
>> 
>> How would this chain if I wanted to do something like:
>> 
>> let median = foo.calculateBigHugeArray().sort().medianValue()
>> 
>> and I want the sort to be done in place.
> 
> I think I can guess what you wanted the above to mean but, mind you, the 
> in-place sort returns `()` so you wouldn't chain its result like that. On the 
> other hand, the above code already works using the non-mutating `.sort()` (to 
> be known as `.sorted()` in Swift 3), and—correct me if I'm wrong—the compiler 
> probably optimises the copy away using copy-on-write anyway.
> 
>> Or will this type of thing just be disallowed in favor of.
>> 
>> let array = foo.calculateBigHugeArray()
>> mutate array.sort()
>> let median = array.medianValue() 
> 
> Yes, I think mutating code should be written in many statements rather than 
> squeezing everything into one long expression.
> 
> Indeed, no currently working method chaining would be disallowed in my 
> proposal. Let's consider the example of "fluent API" for value types, i.e. 
> one where you'd extensively `return self` in `mutating` methods. Firstly, the 
> stdlib doesn't practice that at all. And I failed to find any popular Swift 
> libraries that would do so on Github either. The reason is simple: fluent 
> mutating APIs on value types don't work.
> 
> Consider the following silly example that shortens an array in half (but 
> demonstrates the use of `return self` in a `mutating` method):
> 
> extension Array {
> mutating func halve() -> Array {
> self = self[0 ..< count / 2]
> return self
> }
> }
> 
> Suppose I want to get the result of halving an array twice. What happens?
> 
> var xs = [1,2,3,4,5,6,7,8]
> xs.halve().halve()
> // error: cannot use mutating member on immutable value: function call 
> returns immutable value
> 
> So no, fluent APIs on value types are not a thing in Swift. Not now at least. 
> Making mutation explicit along this proposal has nothing to do with fluent 
> APIs.
> 
>> Alternately you could replace the method invocation operator with &
>> 
>> let median = foo.calculateBigHugeArray()().medianValue()
> 
> Don't you think that's too prone to getting mixed up with the binary `&` 
> operator?
> 
>> Also, if you wanted to stick with consistent & syntax, you could do:
>> 
>> (i)
>> and 
>> let k = ()
> 
> 
> Yeah, probably. However, one place where that notation falls short compared 
> to a prefixing keyword like `mutate` is when mutating `self`:
> 
> extension Array {
> // Apologies for not having the time to think of a less contrived 
> example than this!
> mutating func quarter() {
> mutate self.halve() // Ever since SE-0009 
> ,
>  it's unusual to use `self` here.
> mutate halve()  // Where would you put the `&` prefix in this?
> }
> }
> 
> — Pyry
> 

You are very correct. Yup, that pretty much addresses all of my concerns. So 
count me amongst the fans. 

I had something like popLast in mind, but as you point out, return values are 
immutable in Swift.

struct Foo {
var y = [5, 6]
func foo() -> [Int] {
return y
}
}
var x = Foo()
x.foo().popLast()?.advanced(by: 1) // error: Cannot use mutating member on 
immutable value: function call returns immutable value


Thanks! ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Pyry Jahkola via swift-evolution]

Good that you brought the topic of "fluent" interfaces up. I don't see any 
problem with explicit value type mutation and method chaining because fluent 
interfaces are constrained to reference types by the language. Details below:

> On 28 Apr 2016, at 03:44, Tyler Cloutier  wrote:
> 
> How would this chain if I wanted to do something like:
> 
> let median = foo.calculateBigHugeArray().sort().medianValue()
> 
> and I want the sort to be done in place.

I think I can guess what you wanted the above to mean but, mind you, the 
in-place sort returns `()` so you wouldn't chain its result like that. On the 
other hand, the above code already works using the non-mutating `.sort()` (to 
be known as `.sorted()` in Swift 3), and—correct me if I'm wrong—the compiler 
probably optimises the copy away using copy-on-write anyway.

> Or will this type of thing just be disallowed in favor of.
> 
> let array = foo.calculateBigHugeArray()
> mutate array.sort()
> let median = array.medianValue() 

Yes, I think mutating code should be written in many statements rather than 
squeezing everything into one long expression.

Indeed, no currently working method chaining would be disallowed in my 
proposal. Let's consider the example of "fluent API" for value types, i.e. one 
where you'd extensively `return self` in `mutating` methods. Firstly, the 
stdlib doesn't practice that at all. And I failed to find any popular Swift 
libraries that would do so on Github either. The reason is simple: fluent 
mutating APIs on value types don't work.

Consider the following silly example that shortens an array in half (but 
demonstrates the use of `return self` in a `mutating` method):

extension Array {
mutating func halve() -> Array {
self = self[0 ..< count / 2]
return self
}
}

Suppose I want to get the result of halving an array twice. What happens?

var xs = [1,2,3,4,5,6,7,8]
xs.halve().halve()
// error: cannot use mutating member on immutable value: function call 
returns immutable value

So no, fluent APIs on value types are not a thing in Swift. Not now at least. 
Making mutation explicit along this proposal has nothing to do with fluent APIs.

> Alternately you could replace the method invocation operator with &
> 
> let median = foo.calculateBigHugeArray()().medianValue()

Don't you think that's too prone to getting mixed up with the binary `&` 
operator?

> Also, if you wanted to stick with consistent & syntax, you could do:
> 
> (i)
> and 
> let k = ()


Yeah, probably. However, one place where that notation falls short compared to 
a prefixing keyword like `mutate` is when mutating `self`:

extension Array {
// Apologies for not having the time to think of a less contrived 
example than this!
mutating func quarter() {
mutate self.halve() // Ever since SE-0009 
,
 it's unusual to use `self` here.
mutate halve()  // Where would you put the `&` prefix in this?
}
}

— Pyry

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

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

[Vladimir.S via swift-evolution]

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



Sent from my iPad

On Apr 27, 2016, at 12:37 AM, Thorsten Seitz via swift-evolution
 wrote:


Am 26. April 2016 um 22:02 schrieb Dave Abrahams :



on Tue Apr 26 2016, Thorsten Seitz http://tseitz42-at-icloud.com>> wrote:


Am 23.04.2016 um 10:27 schrieb Pyry Jahkola via swift-evolution
:

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

This is not a new idea. Something almost identical to this has been
explored and discussed quite thoroughly already:

.
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

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

[Howard Lovatt via swift-evolution]

@Tyler,

Excellent summary of concerns which has made me revise my preferences!

I would suggest a few differences from your suggestions (primarily based on
the interpretation of `mutating ` as the name of the method, i.e. the
method name includes `mutating`). The couple of areas I suggest are:

1. Use `mutating` after `func` in declarations: `func mutating
sort(...)`.
2. Use mutating after `.` in calls: `array.mutating sort(<)`
3. Allow mutating for classes:

protocol P { func mutating p() }
class AP: P { func mutating p() { ... }
let aP = AP()
aP.mutating p() // Mutates what `aP` points to

2. Treat mutating as part of name when chaining:

let median = foo.calculateBigHugeArray().mutating
sort().medianValue()


  -- Howard.

On 28 April 2016 at 10:44, Tyler Cloutier via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Apr 23, 2016, at 1:27 AM, Pyry Jahkola via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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:
> .
> 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.
>
> 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. Here's a contrived example of a corner case:
>
> *enum* Error : ErrorType { *case* BadNumber }
>
> *func* demo() *throws* -> Int {
>
> }
>
> * Are assignment methods a redundant way to spell mutating methods?
>  Should we really have both mechanisms?
>
>
> (I had to look up the definition of an *assignment method*. For the
> uninitiated, Dave is talking about what's written here:
> https://github.com/apple/swift/blob/master/docs/proposals/Inplace.rst#use-one-simple-name
> .)
>
> — Yes they are redundant, and no, we should not have both.
>
> With `mutate` required at the call site, we could simply allow both
> overloads `*func* sort()` and `*mutating func* sort()` to coexist,
> because the call sites become unambiguous:
>
> *let* originals = [2, 1, 3, 0, 4, 2]
> *var* copies = originals
>
> originals.sort()   // *warning:* result of call to 'sort()'
> is unused
> *mutate* originals.sort()// *compiler error*
> *let* xs = originals.sort()  // ok
>
> copies.sort() // *warning:* result of call to
> 'sort()' is unused
> *mutate* copies.sort()  // ok
> *let* ys = copies.sort()// ok
> *let* zs = mutate copies.sort() // *warning:* constant 'x' inferred
> to have type '()', which may be unexpected
>
> The language could also allow the use of
>
> *mutate* x.next()
>
> as shorthand for
>
> x = x.next()
>
> when only the non-mutating variant `*func* next() -> *Self*` exists with
> compatible return type.
>
> * Can we really introduce this feature without having a way to apply it
>  to class types?
>
>
> Yes we can. Why complicate the naming of value type members with the
> complexities of reference semantics? The current API naming conventions are
> *good* for reference types which sometimes come with unobvious to obscure
> behaviour (i.e. anything from bumping an internal counter to firing
> missiles and wiping hard drives).
>
> But value types ought to have no side effects (besides memory allocation
> and logging maybe), and so we don't necessarily need that strong a naming
> convention to limit their collateral damage.
>
> If the `mutate` keyword became required for calling `mutating` methods,
> then operators would remain the only place where naming convention were
> needed to distinguish mutation:
>
>
>- Mutating assignment is *explicit*: `xs = [1, 2] + xs + [2, 1]` (i.e.
>`=` without `let` or `var` means mutation)
>- Mutating method call becomes *explicit*: `*mutate* xs.sort()` and `
>*let* x = *mutate* 

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

[Howard Lovatt via swift-evolution]

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: ... {
func mutating sort(...) { ... }
func sort(...) -> [T] { ... }
}

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

As a critique of the `func mutating ` 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 
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 :
> >>
> >>>
> >>> on Tue Apr 26 2016, Thorsten Seitz  wrote:
> >>>
>  Am 23.04.2016 um 10:27 schrieb Pyry Jahkola via swift-evolution
>  :
> 
>  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
>   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 

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

[Tyler Cloutier via swift-evolution]

> On Apr 23, 2016, at 1:27 AM, Pyry Jahkola via swift-evolution 
>  wrote:
> 
> 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 
>> > wrote:
>> 
>> This is not a new idea.  Something almost identical to this has been
>> explored and discussed quite thoroughly already:
>> > >.
>> 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.
> 
> 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. Here's a contrived example of a corner case:
> 
> enum Error : ErrorType { case BadNumber }
> 
> func demo() throws -> Int {
> 
> }
> 
>> * Are assignment methods a redundant way to spell mutating methods?
>>  Should we really have both mechanisms?
> 
> (I had to look up the definition of an assignment method. For the 
> uninitiated, Dave is talking about what's written here: 
> https://github.com/apple/swift/blob/master/docs/proposals/Inplace.rst#use-one-simple-name
>  
> .)
> 
> — Yes they are redundant, and no, we should not have both.
> 
> With `mutate` required at the call site, we could simply allow both overloads 
> `func sort()` and `mutating func sort()` to coexist, because the call sites 
> become unambiguous:
> 
> let originals = [2, 1, 3, 0, 4, 2]
> var copies = originals
> 
> originals.sort()   // warning: result of call to 'sort()' is 
> unused
> mutate originals.sort()// compiler error
> let xs = originals.sort()  // ok
> 
> copies.sort() // warning: result of call to 'sort()' is 
> unused
> mutate copies.sort()  // ok
> let ys = copies.sort()// ok
> let zs = mutate copies.sort() // warning: constant 'x' inferred to have 
> type '()', which may be unexpected
> 
> The language could also allow the use of
> 
> mutate x.next()
> 
> as shorthand for
> 
> x = x.next()
> 
> when only the non-mutating variant `func next() -> Self` exists with 
> compatible return type.
> 
>> * Can we really introduce this feature without having a way to apply it
>>  to class types?
> 
> Yes we can. Why complicate the naming of value type members with the 
> complexities of reference semantics? The current API naming conventions are 
> good for reference types which sometimes come with unobvious to obscure 
> behaviour (i.e. anything from bumping an internal counter to firing missiles 
> and wiping hard drives).
> 
> But value types ought to have no side effects (besides memory allocation and 
> logging maybe), and so we don't necessarily need that strong a naming 
> convention to limit their collateral damage.
> 
> If the `mutate` keyword became required for calling `mutating` methods, then 
> operators would remain the only place where naming convention were needed to 
> distinguish mutation:
> 
> Mutating assignment is explicit: `xs = [1, 2] + xs + [2, 1]` (i.e. `=` 
> without `let` or `var` means mutation)
> Mutating method call becomes explicit: `mutate xs.sort()` and `let x = mutate 
> xs.removeAtIndex(2)`
> Mutating function arguments are explicit with the `&` prefix: `swap(, )`
> Mutating operators are implicit and by convention, should end with the `=` 
> symbol: `xs += [8, 9]`
> Reference types have no notion of `mutating` members (and probably ought to 
> remain that way) so they mutate implicitly.
> 
>> I should also point out that under the assignment method paradigm one
>> would probably need to re-evalutate rules for naming.  Under the current
>> API guidelines' approach, we'd write:
>> 
>>x.=sorted()  // sort x in-place
>> 
>> and I am not sure how easy that would be for people to swallow
>> considering how much more straightforward
>> 
>>x.sort() // 

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

[Michael Peternell via swift-evolution]

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 
> :
> 
> 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 
>  wrote:
> 
> 
> Sent from my iPad
> 
> On Apr 27, 2016, at 12:37 AM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
>> Am 26. April 2016 um 22:02 schrieb Dave Abrahams :
>> 
>>> 
>>> on Tue Apr 26 2016, Thorsten Seitz  wrote:
>>> 
 Am 23.04.2016 um 10:27 schrieb Pyry Jahkola via swift-evolution
 :
 
 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
  wrote:
 
 This is not a new idea. Something almost identical to this has been
 explored and discussed quite thoroughly already:
 .
 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
> 

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Apr 27, 2016, at 12:37 AM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
>> Am 26. April 2016 um 22:02 schrieb Dave Abrahams :
>> 
>> 
>>> on Tue Apr 26 2016, Thorsten Seitz  wrote:
>>> 
>>> Am 23.04.2016 um 10:27 schrieb Pyry Jahkola via swift-evolution
>>> :
>>> 
>>> 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
>>>  wrote:
>>> 
>>> This is not a new idea. Something almost identical to this has been
>>> explored and discussed quite thoroughly already:
>>> .
>>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Thorsten Seitz via swift-evolution]

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

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

[Dave Abrahams via swift-evolution]

on Tue Apr 26 2016, Thorsten Seitz  wrote:

> Am 23.04.2016 um 10:27 schrieb Pyry Jahkola via swift-evolution
> :
>
> 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
>  wrote:
>
> This is not a new idea. Something almost identical to this has been
> explored and discussed quite thoroughly already:
> 
> .
> 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
something like this via a new evolution proposal.  However, anything
like that is way out of scope for Swift 3, and in the absence of new
information, it isn’t a productive use of time to rehash it at all.

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

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

[Haravikk via swift-evolution]

> On 26 Apr 2016, at 14:48, Thorsten Seitz via swift-evolution 
>  wrote:
> 
>> 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).
> I'm wondering how to deal with fluent interfaces which do mutate the receiver 
> and return 'self', i.e. the builder pattern. I think we can simply require 
> that such a chained expression is required to consist of only mutating calls 
> (or only non-mutating calls), so that one 'mutate' for the whole expression 
> would be sufficient.
> Expressions combining mutating calls to different receivers which have return 
> values would simply be prohibited. This would probably be bad style anyway 
> (contrary to the fluent example), or does anyone have a good counter example?

If we do go ahead with this then put me in the “mutate” camp, as I’d actually 
prefer to see & on inout variables be replaced by the inout keyword at the 
call-site for consistency. That said, the reason I want that is because inout 
variables are fairly uncommon (though with indexing changes that will change), 
but it also looks fairly ugly IMO.


Still, for the feature itself I’m of two minds; the naming convention was just 
changed to enable clear distinctions between mutating and non-mutating methods, 
but if we had this feature that distinction wouldn’t actually be necessary, we 
can just call all forms of sorting .sort() and the mutate keyword (or lack of) 
would distinguish which one is meant, and failure to use a return value would 
pick up on mistakes. I’d hate to go through the whole naming debate again, but 
at the same time that would be simpler in a way.


So I’m a +1 if we can also use it to roll mutating and non-mutating methods 
under the same name, even though I don’t want to go through the naming 
transition all over again ;)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

I like this idea very much. I believe '&' should belong to instance 
variable, as it will be mutated, just like for inout parameter, so


c&.frobnicate(i)
let k = c&.frobnicate()

very clear and explicit. Don't like the 'mutation' or even 'mut' as we'll 
have heavy code, as it is a word just like functions/methods/variable names 
and IMO harder to parse visually. '&' is a 'marker', that clearly parsed.


On 26.04.2016 16:48, Thorsten Seitz via swift-evolution wrote:


As an alternative to the mutate keyword I rather like using '&' because it
already means 'inout'. Using '&.' as mutating method call would therefore
be quite understandable.

c&.frobnicate(i)
let k = c&.frobnicate()

Or marking the method like suggested elsewhere:

c.frobnicate&(i)
let k = c.frobnicate&()

-Thorsten

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

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

[Dave Abrahams via swift-evolution]

on Mon Apr 25 2016, Xiaodi Wu  wrote:

> Me:
>
> Unless the functions also return an error, mutating/non-mutating pairs
> of functions return Void/Self (or maybe Optional) respectively.
> Are there other possibilities? But Swift is pretty unique among
> C-family languages in allowing overloaded functions that differ only
> by return type. Besides the loss of clarity to the reader at the call
> site, what are downsides of simply naming both functions exactly the
> same in today's Swift syntax?
>
> You:
>
> I don't think it's really worth exploring much further once you
> acknowledge the loss of clarity to the reader at the call site ;-)
>
> (I think the smiley really seals the deal in terms of definitiveness of
> rejection, no?)

Hey, that was just my opinion at the time; that doesn't mean the
community rejected the idea or the core team rejected the idea [or even
that I still believe the same thing this week ;-)]

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

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

[Xiaodi Wu via swift-evolution]

Me:

Unless the functions also return an error, mutating/non-mutating pairs
of functions return Void/Self (or maybe Optional) respectively.
Are there other possibilities? But Swift is pretty unique among
C-family languages in allowing overloaded functions that differ only
by return type. Besides the loss of clarity to the reader at the call
site, what are downsides of simply naming both functions exactly the
same in today's Swift syntax?

You:

I don't think it's really worth exploring much further once you acknowledge
the loss of clarity to the reader at the call site ;-)

(I think the smiley really seals the deal in terms of definitiveness of
rejection, no?)
On Mon, Apr 25, 2016 at 17:05 Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Sun Apr 24 2016, Xiaodi Wu  wrote:
>
> > Anyways, I wouldn’t be surprised if this idea has come up before and
> has
> > been rejected, but to me it sounds like a good idea.
> >
> > Yes, I suggested this a while back, and it was rejected.
>
> That makes it sound much more definitive than anything on this list
> other than a formal review response can ever be.  What actually
> happened?
>
> --
> Dave
>
> ___
> 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

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

[Dave Abrahams via swift-evolution]

on Sun Apr 24 2016, Xiaodi Wu  wrote:

> Anyways, I wouldn’t be surprised if this idea has come up before and has
> been rejected, but to me it sounds like a good idea.
>
> Yes, I suggested this a while back, and it was rejected.

That makes it sound much more definitive than anything on this list
other than a formal review response can ever be.  What actually
happened?

-- 
Dave

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

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

[Dave Abrahams via swift-evolution]

on Mon Apr 25 2016, Radosław Pietruszewski  wrote:

> Q: Would it be possible to allow some sigil in method names (say, 
> prefix/postfix
> `=`) without any automatic/magic treatment of these methods?

Almost anything is possible ;-).

> In Ruby, after all, postfix `!` is just allowed in names. It doesn’t have any
> semantic meaning for the interpreter, it’s just the (strong, well agreed upon)
> convention to use it to mark mutating methods in mutating/non-mutating pairs,
> like `foo.map(…)` vs `foo.map!(…)`.
>
> It works out well for Ruby. Would it be out of question to allow the same 
> thing
> in Swift? A naming convention (`foo.sort()` vs `foo.sort=()`), not an 
> automatic
> language feature?

I don't think we'd want to allow this without tying it to mutation; just IMO.

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

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

[Goffredo Marocchi via swift-evolution]

Hello Dave,

> That makes these people suspicious of language features that could
> threaten to make classes “second-class citizens.”


...and that is unfortunate when emotions and resistance to positive change 
worsen the discussion, but if you take a look at discussion related to abstract 
classes and methods, there is not a lack of "POP is the new way, why dedicate 
time on this at all, let's invest in protocols alone..." kind of comments 
fearing that protocols did not receive deserved preferential treatment.

[[iOS messageWithData:ideas] broadcast]

> On 25 Apr 2016, at 19:48, Dave Abrahams via swift-evolution 
>  wrote:
> 
> That makes these people suspicious of language features that could
> threaten to make classes “second-class citizens.”
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Sat Apr 23 2016, Pyry Jahkola  wrote:

> 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
>  wrote:
>
> This is not a new idea. Something almost identical to this has been
> explored and discussed quite thoroughly already:
> .
> 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.
>
> 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)
> }

Not that syntax is the most important question here, but that syntax is
super-heavyweight by comparison and unlikely to fly with many people
(including me) for that reason.

> 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. Here's a contrived example of a corner case:
>
> enum Error : ErrorType { case BadNumber }
>
> func demo() throws -> Int {
> }
>
> * Are assignment methods a redundant way to spell mutating methods?
> Should we really have both mechanisms?
>
> (I had to look up the definition of an assignment method. For the uninitiated,
> Dave is talking about what's written here:
> https://github.com/apple/swift/blob/master/docs/proposals/Inplace.rst#use-one-simple-name.)
>
> — Yes they are redundant, and no, we should not have both.
>
> With `mutate` required at the call site, we could simply allow both overloads
> `func sort()` and `mutating func sort()` to coexist, because the call sites
> become unambiguous:
>
> let originals = [2, 1, 3, 0, 4, 2]
> var copies = originals
>
> originals.sort() // warning: result of call to 'sort()' is unused
> mutate originals.sort() // compiler error
> let xs = originals.sort() // ok
>
> copies.sort() // warning: result of call to 'sort()' is unused
> mutate copies.sort() // ok
> let ys = copies.sort() // ok
> let zs = mutate copies.sort() // warning: constant 'x' inferred to have type '
> ()', which may be unexpected
>
> The language could also allow the use of
>
> mutate x.next()
>
> as shorthand for
>
> x = x.next()
>
> when only the non-mutating variant `func next() -> Self` exists with
> compatible return type.
>
> * Can we really introduce this feature without having a way to apply it
> to class types?
>
> Yes we can. Why complicate the naming of value type members with the
> complexities of reference semantics? 

Because some people still imagine that classes should have all the same
basic capabilities as value types, and that protocols should unify them.
That makes these people suspicious of language features that could
threaten to make classes “second-class citizens.”

Maybe the Foundation value types effort will begin to change that; I'm
not sure.

> The current API naming conventions are good for reference types which
> sometimes come with unobvious to obscure behaviour (i.e. anything from
> bumping an internal counter to firing missiles and wiping hard
> drives).
>
> But value types ought to have no side effects (besides memory allocation and
> logging maybe), and so we don't necessarily need that strong a naming 
> convention
> to limit their collateral damage.
>
> If the `mutate` keyword became required for calling `mutating` methods, then
> operators would remain the only place where naming convention were needed to
> distinguish mutation:
>
> * Mutating assignment is explicit: `xs = [1, 2] + xs + [2, 1]` (i.e. `=` 
> without
>   `let` or `var` means mutation)
> * Mutating method call becomes explicit: `mutate xs.sort()` and `let x = 
> mutate
>   xs.removeAtIndex(2)`
> * Mutating function arguments are explicit with the `&` prefix: `swap(, 
> )`
> * Mutating operators are implicit and by convention, should end with the `=`
>   symbol: `xs += [8, 9]`
> * Reference types have no notion of `mutating` members (and probably ought to
>   remain that way) so they mutate implicitly.
>
> I should also point out that under the assignment method paradigm one
> would probably need to re-evalutate rules for naming. Under the current
> API guidelines' approach, we'd write:
>
> x.=sorted() // sort x in-place
>
> and I am not 

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

[Radosław Pietruszewski via swift-evolution]

Q: Would it be possible to allow some sigil in method names (say, 
prefix/postfix `=`) without any automatic/magic treatment of these methods?

In Ruby, after all, postfix `!` is just allowed in names. It doesn’t have any 
semantic meaning for the interpreter, it’s just the (strong, well agreed upon) 
convention to use it to mark mutating methods in mutating/non-mutating pairs, 
like `foo.map(…)` vs `foo.map!(…)`.

It works out well for Ruby. Would it be out of question to allow the same thing 
in Swift? A naming convention (`foo.sort()` vs `foo.sort=()`), not an automatic 
language feature?

— Radek

> On 22 Apr 2016, at 23:24, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> 
> on Thu Apr 21 2016, Daniel Steinberg  > wrote:
> 
>> Pardon me if this has been raised before.
>> 
>> I gave a short presentation at our Cleveland CocoaHeads this week on
>> what is coming in Swift 3. One of the attendees stayed behind to ask
>> about the naming guidelines for mutating vs non-mutating. He is fairly
>> new to Swift - coming from Ruby. I have no Ruby experience but am
>> passing his thoughts on to this list.
>> 
>> He said that in Ruby they decorate the name with a symbol (I believe
>> in their case it is “!”) to distinguish between the two. Although
>> usually I’m not a fan of such naming conventions, we do something
>> similar with inout parameters.
>> 
>> For example, if we have
>> 
>> func myFunc(param: inout String) { …}
>> 
>> we call it like this (using the Swift 3 first label convention)
>> 
>> myFunc(param: )
>> 
>> We use the & to signal that the value of aName might be changed by the call 
>> to myFunc().
>> 
>> Similarly, instead of settling on a naming convention for verb vs
>> verbed/verbing we could name the methods descriptively and require a
>> symbol (here I use & but only for illustration) to distinguish between
>> mutating and non-mutating
>> 
>> so we would have 
>> 
>> myArray.sort&()
>> 
>> and
>> 
>> sortedArray = myArray.sort()
>> 
>> Xcode and other tools could enforce this naming pattern and warn us
>> that a mutating method must end in “&” and that a non-mutating method
>> is not allowed to.
> 
> This is not a new idea.  Something almost identical to this has been
> explored and discussed quite thoroughly already:
>  >.
> In fact, it was implmented and later reverted because it raised
> language-design questions for which we had no good answers.  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?
> 
> * Are assignment methods a redundant way to spell mutating methods?
>  Should we really have both mechanisms?
> 
> * Can we really introduce this feature without having a way to apply it
>  to class types?
> 
> I should also point out that under the assignment method paradigm one
> would probably need to re-evalutate rules for naming.  Under the current
> API guidelines' approach, we'd write:
> 
>x.=sorted()  // sort x in-place
> 
> and I am not sure how easy that would be for people to swallow
> considering how much more straightforward
> 
>x.sort() // current way to sort x in-place
> 
> is, and because the language now contains explicit notation for
> mutation, it becomes harder to argue against theis pair:
> 
>y = x.sort()
>x.=sort()  // sort x in place
> 
> Lastly, I should point out that the proposal does nothing to solve the
> problem of `c.formSuccessor()`, since that doesn't mutate the
> receiver.
> 
> I still like the proposal's basic approach and would love to see it used
> to address these naming problems, but I want to be clear that it's by no
> means a panacea and there are real obstacles between here and actually
> being able to apply it.  If you want to move forward with something like
> this, you need to solve the problems described above.
> 
> -- 
> Dave
> 
> ___
> 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

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

[Vladimir.S via swift-evolution]

On 24.04.2016 17:49, Tim Vermeulen via swift-evolution wrote:

Can’t we do this for every mutating method? i.e.

var numbers = [1,3,2]
let sorted = numbers.sort()
// sorted is [1,2,3], numbers is [1,3,2]
numbers.sort()
// numbers is [1,2,3]

I suppose this would require that the mutating version doesn’t return anything, 
and I don’t know if that’s ever a problem.


Well, right now(Swift 2) we can have such code (yes, it will raise 
warnings, but will compile and run without errors. i.e. this is a valid code):


var a = [1,2,3]
let a1 = a.sortInPlace(>) // a1 == ()
let a2 = a.sort(>) // a2 == [3,2,1]

Note, how sortInPlace is explicit. Now, change to sort/sorted:

var a = [1,2,3]
let a1 = a.sorted(>) // IMO not explicit about the result
let a2 = a.sort(>)

For your proposal we need to disallow assignment of Void to variable, 
otherwise compiller can't choose which one to use. Or, in case of your 
proposal, documentation should explicitly say(and compiler implemented in 
this way) that non-mutating function should be selected if result is used.

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

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

[Xiaodi Wu via swift-evolution]

On Sun, Apr 24, 2016 at 11:01 AM, Tim Vermeulen via swift-evolution <
swift-evolution@swift.org> wrote:

> > The idea of distinguishing all mutating/non-mutating functions with only
> the assignment operator did occur to me as I wrote that.
> > Using such a rule would allow automatic generation of mutating methods
> from non-mutating ones, since the naming would no longer need changing.
> > However, this would also mean scrapping half the Naming Guidelines, so
> I'm hesitant to put that possibility forward as a serious proposal.
> >
> > I think union (verb) vs union (noun) would work as a one off, though,
> since it fits the guidelines as they currently stand. It would be a nice
> way to demonstrate that the compiler can make the distinction in a public
> API.
> >
> > > From James F
> > On 24 Apr 2016, at 15:49, Tim Vermeulenwrote:
> >
> > > > The whole naming issue seems to be caused by the .union(_:)
> function. The Swift Guidelines say that mutating functions should use a
> verb, and non-mutating forms should use a noun, but in this case, the word
> union itself is a verb and a noun.
> > > >
> > > > Have we considered this, then:
> > > >
> > > > a.union(b) //mutating
> > > >
> > > > _ = a.union(b) //non-mutating
> > > >
> > > > There is no ambiguity in most situations, and the fact the Swift
> compiler can't disambiguate this at the moment is a bug I'd like to see
> fixed in the Swift 3 timeframe. I think this wouldn't be such a bad
> compromise, and other functions could still use the standard -ed/-ing
> system alongside this without the API looking inconsistent, unlike with the
> form- prefix.
> > > >
> > > > Admittedly, there is merit to the idea that functional methods
> should make non-mutating forms the primary form, but I feel like we should
> figure out what our stance is on this methodology in general. A mention in
> the Guidelines one way or the other would be nice, since the current rules
> seem to support this.
> > > >
> > > > > From James F
> > >
> > > Can’t we do this for every mutating method? i.e.
> > >
> > > var numbers = [1,3,2]
> > > let sorted = numbers.sort()
> > > // sorted is [1,2,3], numbers is [1,3,2]
> > > numbers.sort()
> > > // numbers is [1,2,3]
> > >
> > > I suppose this would require that the mutating version doesn’t return
> anything, and I don’t know if that’s ever a problem.
> >
> >
> >
>
> Well, this change would render a big part of the naming guidelines
> meaningless, but isn’t that a good thing? Guidelines are often in place to
> prevent ambiguity, and this solution would do that without the need for
> guidelines.
>
> Anyways, I wouldn’t be surprised if this idea has come up before and has
> been rejected, but to me it sounds like a good idea.
>

Yes, I suggested this a while back, and it was rejected.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tim Vermeulen via swift-evolution]

> The idea of distinguishing all mutating/non-mutating functions with only the 
> assignment operator did occur to me as I wrote that.
> Using such a rule would allow automatic generation of mutating methods from 
> non-mutating ones, since the naming would no longer need changing.
> However, this would also mean scrapping half the Naming Guidelines, so I'm 
> hesitant to put that possibility forward as a serious proposal.
> 
> I think union (verb) vs union (noun) would work as a one off, though, since 
> it fits the guidelines as they currently stand. It would be a nice way to 
> demonstrate that the compiler can make the distinction in a public API.
> 
> > From James F
> On 24 Apr 2016, at 15:49, Tim Vermeulenwrote:
> 
> > > The whole naming issue seems to be caused by the .union(_:) function. The 
> > > Swift Guidelines say that mutating functions should use a verb, and 
> > > non-mutating forms should use a noun, but in this case, the word union 
> > > itself is a verb and a noun.
> > > 
> > > Have we considered this, then:
> > > 
> > > a.union(b) //mutating
> > > 
> > > _ = a.union(b) //non-mutating
> > > 
> > > There is no ambiguity in most situations, and the fact the Swift compiler 
> > > can't disambiguate this at the moment is a bug I'd like to see fixed in 
> > > the Swift 3 timeframe. I think this wouldn't be such a bad compromise, 
> > > and other functions could still use the standard -ed/-ing system 
> > > alongside this without the API looking inconsistent, unlike with the 
> > > form- prefix.
> > > 
> > > Admittedly, there is merit to the idea that functional methods should 
> > > make non-mutating forms the primary form, but I feel like we should 
> > > figure out what our stance is on this methodology in general. A mention 
> > > in the Guidelines one way or the other would be nice, since the current 
> > > rules seem to support this.
> > > 
> > > > From James F
> > 
> > Can’t we do this for every mutating method? i.e.
> > 
> > var numbers = [1,3,2]
> > let sorted = numbers.sort()
> > // sorted is [1,2,3], numbers is [1,3,2]
> > numbers.sort()
> > // numbers is [1,2,3]
> > 
> > I suppose this would require that the mutating version doesn’t return 
> > anything, and I don’t know if that’s ever a problem.
> 
> 
> 

Well, this change would render a big part of the naming guidelines meaningless, 
but isn’t that a good thing? Guidelines are often in place to prevent 
ambiguity, and this solution would do that without the need for guidelines.

Anyways, I wouldn’t be surprised if this idea has come up before and has been 
rejected, but to me it sounds like a good idea.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[James Froggatt via swift-evolution]

The idea of distinguishing all mutating/non-mutating functions with only the 
assignment operator did occur to me as I wrote that.
Using such a rule would allow automatic generation of mutating methods from 
non-mutating ones, since the naming would no longer need changing.
However, this would also mean scrapping half the Naming Guidelines, so I'm 
hesitant to put that possibility forward as a serious proposal.

I think union (verb) vs union (noun) would work as a one off, though, since it 
fits the guidelines as they currently stand. It would be a nice way to 
demonstrate that the compiler can make the distinction in a public API.

From James F

On 24 Apr 2016, at 15:49, Tim Vermeulen  wrote:

>> The whole naming issue seems to be caused by the .union(_:) function. The 
>> Swift Guidelines say that mutating functions should use a verb, and 
>> non-mutating forms should use a noun, but in this case, the word union 
>> itself is a verb and a noun.
>> 
>> Have we considered this, then:
>> 
>> a.union(b) //mutating
>> 
>> _ = a.union(b) //non-mutating
>> 
>> There is no ambiguity in most situations, and the fact the Swift compiler 
>> can't disambiguate this at the moment is a bug I'd like to see fixed in the 
>> Swift 3 timeframe. I think this wouldn't be such a bad compromise, and other 
>> functions could still use the standard -ed/-ing system alongside this 
>> without the API looking inconsistent, unlike with the form- prefix.
>> 
>> Admittedly, there is merit to the idea that functional methods should make 
>> non-mutating forms the primary form, but I feel like we should figure out 
>> what our stance is on this methodology in general. A mention in the 
>> Guidelines one way or the other would be nice, since the current rules seem 
>> to support this.
>> 
>>> From James F
> 
> Can’t we do this for every mutating method? i.e.
> 
> var numbers = [1,3,2]
> let sorted = numbers.sort()
> // sorted is [1,2,3], numbers is [1,3,2]
> numbers.sort()
> // numbers is [1,2,3]
> 
> I suppose this would require that the mutating version doesn’t return 
> anything, and I don’t know if that’s ever a problem.

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

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

[Tim Vermeulen via swift-evolution]

> The whole naming issue seems to be caused by the .union(_:) function. The 
> Swift Guidelines say that mutating functions should use a verb, and 
> non-mutating forms should use a noun, but in this case, the word union itself 
> is a verb and a noun.
> 
> Have we considered this, then:
> 
> a.union(b) //mutating
> 
> _ = a.union(b) //non-mutating
> 
> There is no ambiguity in most situations, and the fact the Swift compiler 
> can't disambiguate this at the moment is a bug I'd like to see fixed in the 
> Swift 3 timeframe. I think this wouldn't be such a bad compromise, and other 
> functions could still use the standard -ed/-ing system alongside this without 
> the API looking inconsistent, unlike with the form- prefix.
> 
> Admittedly, there is merit to the idea that functional methods should make 
> non-mutating forms the primary form, but I feel like we should figure out 
> what our stance is on this methodology in general. A mention in the 
> Guidelines one way or the other would be nice, since the current rules seem 
> to support this.
> 
> > From James F
> 
> 
> 

Can’t we do this for every mutating method? i.e.

var numbers = [1,3,2]
let sorted = numbers.sort()
// sorted is [1,2,3], numbers is [1,3,2]
numbers.sort()
// numbers is [1,2,3]

I suppose this would require that the mutating version doesn’t return anything, 
and I don’t know if that’s ever a problem.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Patrick Smith via swift-evolution]

Yes +1 I think how the compiler can’t work with two methods with the same name, 
where one has a result, and other mutating, needs to be fixed to enable nice 
APIs.

Patrick




On Sun, Apr 24, 2016 at 2:33 AM -0700, "James Froggatt via swift-evolution" 
 wrote:










The whole naming issue seems to be caused by the .union(_:) function. The Swift 
Guidelines say that mutating functions should use a verb, and non-mutating 
forms should use a noun, but in this case, the word union itself is a verb and 
a noun.

Have we considered this, then:

a.union(b) //mutating

_ = a.union(b) //non-mutating

There is no ambiguity in most situations, and the fact the Swift compiler can't 
disambiguate this at the moment is a bug I'd like to see fixed in the Swift 3 
timeframe. I think this wouldn't be such a bad compromise, and other functions 
could still use the standard -ed/-ing system alongside this without the API 
looking inconsistent, unlike with the form- prefix.

Admittedly, there is merit to the idea that functional methods should make 
non-mutating forms the primary form, but I feel like we should figure out what 
our stance is on this methodology in general. A mention in the Guidelines one 
way or the other would be nice, since the current rules seem to support this.

From James F
___
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

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

[James Froggatt via swift-evolution]

The whole naming issue seems to be caused by the .union(_:) function. The Swift 
Guidelines say that mutating functions should use a verb, and non-mutating 
forms should use a noun, but in this case, the word union itself is a verb and 
a noun.

Have we considered this, then:

a.union(b) //mutating

_ = a.union(b) //non-mutating

There is no ambiguity in most situations, and the fact the Swift compiler can't 
disambiguate this at the moment is a bug I'd like to see fixed in the Swift 3 
timeframe. I think this wouldn't be such a bad compromise, and other functions 
could still use the standard -ed/-ing system alongside this without the API 
looking inconsistent, unlike with the form- prefix.

Admittedly, there is merit to the idea that functional methods should make 
non-mutating forms the primary form, but I feel like we should figure out what 
our stance is on this methodology in general. A mention in the Guidelines one 
way or the other would be nice, since the current rules seem to support this.

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

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

[Pyry Jahkola via swift-evolution]

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 
>  wrote:
> 
> This is not a new idea.  Something almost identical to this has been
> explored and discussed quite thoroughly already:
>  >.
> 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.

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. Here's 
a contrived example of a corner case:

enum Error : ErrorType { case BadNumber }

func demo() throws -> Int {

}

> * Are assignment methods a redundant way to spell mutating methods?
>  Should we really have both mechanisms?

(I had to look up the definition of an assignment method. For the uninitiated, 
Dave is talking about what's written here: 
https://github.com/apple/swift/blob/master/docs/proposals/Inplace.rst#use-one-simple-name
 
.)

— Yes they are redundant, and no, we should not have both.

With `mutate` required at the call site, we could simply allow both overloads 
`func sort()` and `mutating func sort()` to coexist, because the call sites 
become unambiguous:

let originals = [2, 1, 3, 0, 4, 2]
var copies = originals

originals.sort()   // warning: result of call to 'sort()' is unused
mutate originals.sort()// compiler error
let xs = originals.sort()  // ok

copies.sort() // warning: result of call to 'sort()' is 
unused
mutate copies.sort()  // ok
let ys = copies.sort()// ok
let zs = mutate copies.sort() // warning: constant 'x' inferred to have 
type '()', which may be unexpected

The language could also allow the use of

mutate x.next()

as shorthand for

x = x.next()

when only the non-mutating variant `func next() -> Self` exists with compatible 
return type.

> * Can we really introduce this feature without having a way to apply it
>  to class types?

Yes we can. Why complicate the naming of value type members with the 
complexities of reference semantics? The current API naming conventions are 
good for reference types which sometimes come with unobvious to obscure 
behaviour (i.e. anything from bumping an internal counter to firing missiles 
and wiping hard drives).

But value types ought to have no side effects (besides memory allocation and 
logging maybe), and so we don't necessarily need that strong a naming 
convention to limit their collateral damage.

If the `mutate` keyword became required for calling `mutating` methods, then 
operators would remain the only place where naming convention were needed to 
distinguish mutation:

Mutating assignment is explicit: `xs = [1, 2] + xs + [2, 1]` (i.e. `=` without 
`let` or `var` means mutation)
Mutating method call becomes explicit: `mutate xs.sort()` and `let x = mutate 
xs.removeAtIndex(2)`
Mutating function arguments are explicit with the `&` prefix: `swap(, )`
Mutating operators are implicit and by convention, should end with the `=` 
symbol: `xs += [8, 9]`
Reference types have no notion of `mutating` members (and probably ought to 
remain that way) so they mutate implicitly.

> I should also point out that under the assignment method paradigm one
> would probably need to re-evalutate rules for naming.  Under the current
> API guidelines' approach, we'd write:
> 
>x.=sorted()  // sort x in-place
> 
> and I am not sure how easy that would be for people to swallow
> considering how much more straightforward
> 
>x.sort() // current way to sort x in-place
> 
> is, and because the language now contains explicit notation for
> mutation, it becomes harder to argue against theis pair:
> 
>y = x.sort()
>x.=sort()  // sort x in place

I agree that the current API guidelines wouldn't work for value types anymore. 
Both `sort` and `sorted` would be called `sort`.

> Lastly, I 

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

[Daniel Steinberg via swift-evolution]

Thank you Dave.

I appreciate your thoughtful and complete response and will think further on 
this.

Daniel
> On Apr 22, 2016, at 11:24 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> 
> on Thu Apr 21 2016, Daniel Steinberg  wrote:
> 
>> Pardon me if this has been raised before.
>> 
>> I gave a short presentation at our Cleveland CocoaHeads this week on
>> what is coming in Swift 3. One of the attendees stayed behind to ask
>> about the naming guidelines for mutating vs non-mutating. He is fairly
>> new to Swift - coming from Ruby. I have no Ruby experience but am
>> passing his thoughts on to this list.
>> 
>> He said that in Ruby they decorate the name with a symbol (I believe
>> in their case it is “!”) to distinguish between the two. Although
>> usually I’m not a fan of such naming conventions, we do something
>> similar with inout parameters.
>> 
>> For example, if we have
>> 
>> func myFunc(param: inout String) { …}
>> 
>> we call it like this (using the Swift 3 first label convention)
>> 
>> myFunc(param: )
>> 
>> We use the & to signal that the value of aName might be changed by the call 
>> to myFunc().
>> 
>> Similarly, instead of settling on a naming convention for verb vs
>> verbed/verbing we could name the methods descriptively and require a
>> symbol (here I use & but only for illustration) to distinguish between
>> mutating and non-mutating
>> 
>> so we would have 
>> 
>> myArray.sort&()
>> 
>> and
>> 
>> sortedArray = myArray.sort()
>> 
>> Xcode and other tools could enforce this naming pattern and warn us
>> that a mutating method must end in “&” and that a non-mutating method
>> is not allowed to.
> 
> This is not a new idea.  Something almost identical to this has been
> explored and discussed quite thoroughly already:
> .
> In fact, it was implmented and later reverted because it raised
> language-design questions for which we had no good answers.  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?
> 
> * Are assignment methods a redundant way to spell mutating methods?
>  Should we really have both mechanisms?
> 
> * Can we really introduce this feature without having a way to apply it
>  to class types?
> 
> I should also point out that under the assignment method paradigm one
> would probably need to re-evalutate rules for naming.  Under the current
> API guidelines' approach, we'd write:
> 
>x.=sorted()  // sort x in-place
> 
> and I am not sure how easy that would be for people to swallow
> considering how much more straightforward
> 
>x.sort() // current way to sort x in-place
> 
> is, and because the language now contains explicit notation for
> mutation, it becomes harder to argue against theis pair:
> 
>y = x.sort()
>x.=sort()  // sort x in place
> 
> Lastly, I should point out that the proposal does nothing to solve the
> problem of `c.formSuccessor()`, since that doesn't mutate the
> receiver.
> 
> I still like the proposal's basic approach and would love to see it used
> to address these naming problems, but I want to be clear that it's by no
> means a panacea and there are real obstacles between here and actually
> being able to apply it.  If you want to move forward with something like
> this, you need to solve the problems described above.
> 
> -- 
> Dave
> 
> ___
> 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

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

[Dave Abrahams via swift-evolution]

on Thu Apr 21 2016, Daniel Steinberg  wrote:

> Pardon me if this has been raised before.
>
> I gave a short presentation at our Cleveland CocoaHeads this week on
> what is coming in Swift 3. One of the attendees stayed behind to ask
> about the naming guidelines for mutating vs non-mutating. He is fairly
> new to Swift - coming from Ruby. I have no Ruby experience but am
> passing his thoughts on to this list.
>
> He said that in Ruby they decorate the name with a symbol (I believe
> in their case it is “!”) to distinguish between the two. Although
> usually I’m not a fan of such naming conventions, we do something
> similar with inout parameters.
>
> For example, if we have
>
> func myFunc(param: inout String) { …}
>
> we call it like this (using the Swift 3 first label convention)
>
> myFunc(param: )
>
> We use the & to signal that the value of aName might be changed by the call 
> to myFunc().
>
> Similarly, instead of settling on a naming convention for verb vs
> verbed/verbing we could name the methods descriptively and require a
> symbol (here I use & but only for illustration) to distinguish between
> mutating and non-mutating
>
> so we would have 
>
> myArray.sort&()
>
> and
>
> sortedArray = myArray.sort()
>
> Xcode and other tools could enforce this naming pattern and warn us
> that a mutating method must end in “&” and that a non-mutating method
> is not allowed to.

This is not a new idea.  Something almost identical to this has been
explored and discussed quite thoroughly already:
.
In fact, it was implmented and later reverted because it raised
language-design questions for which we had no good answers.  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?

* Are assignment methods a redundant way to spell mutating methods?
  Should we really have both mechanisms?

* Can we really introduce this feature without having a way to apply it
  to class types?

I should also point out that under the assignment method paradigm one
would probably need to re-evalutate rules for naming.  Under the current
API guidelines' approach, we'd write:

x.=sorted()  // sort x in-place

and I am not sure how easy that would be for people to swallow
considering how much more straightforward

x.sort() // current way to sort x in-place

is, and because the language now contains explicit notation for
mutation, it becomes harder to argue against theis pair:

y = x.sort()
x.=sort()  // sort x in place

Lastly, I should point out that the proposal does nothing to solve the
problem of `c.formSuccessor()`, since that doesn't mutate the
receiver.

I still like the proposal's basic approach and would love to see it used
to address these naming problems, but I want to be clear that it's by no
means a panacea and there are real obstacles between here and actually
being able to apply it.  If you want to move forward with something like
this, you need to solve the problems described above.

-- 
Dave

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

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

[T.J. Usiyan via swift-evolution]

The benefit, as I see it, to this approach is not that it reduces noise. It
is that it standardizes the naming decision in a broadly applicable manner.
Look at the discussion that took place around `union` and `formUnion` to
see that this standardization could be beneficial. The argument that this
would 'add noise' seems flawed to me, since there is at least as much
'noise' in distinguishing between `sort` and `sorted`.

All of that said, I do have a concern that whatever character we use might
be too subtle or easily confused with some other meaning. I understand that
`&` was just a suggestion but, for example, the proximity to another place
where that glyph would be valid and have a different meaning is a potential
issue.

I think that we should seriously consider this, 'noise' ideas aside. If we
could agree on a convention that didn't need to consider the specific
grammar of the methods,  we would have removed a major wrinkle in designing
Swift APIs.

TJ

On Fri, Apr 22, 2016 at 8:04 AM, Patrick Smith via swift-evolution <
swift-evolution@swift.org> wrote:

> Well, you could actually have something like this now, and use whether the
> returned result was used or not to know if was a mutating or nonmutating
> method or not.
>
> Patrick
>
>
>
>
> On Fri, Apr 22, 2016 at 4:53 AM -0700, "James Campbell via
> swift-evolution"  wrote:
>
> What if we had a concept similar to errors and try ?
>>
>> Given this function:
>>
>> func sort() -> Self {
>> }
>>
>> mutating sort() -> Self {
>> }
>>
>>
>> If a developer calls:
>>
>> array.sort()
>>
>> It will sort a copy of that array, in order to sort in place the
>> developer must confirm the mutation like so:
>>
>> mutate array.sort()
>>
>> This will then call the mutating version of sort :)
>>
>> *___*
>>
>> *James⎥Chief Of Fun*
>>
>> *ja...@supmenow.com ⎥supmenow.com
>> *
>>
>> *Sup*
>>
>> *Runway East *
>>
>> *10 Finsbury Square*
>>
>> *London*
>>
>> * EC2A 1AF *
>>
>> On 22 April 2016 at 12:31, Haravikk via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> This is why I mentioned Xcode; while we can have ampersand as a language
>>> feature for marking such things explicitly (i.e- developer consents to
>>> doing it), we could also just have Xcode highlight inout parameters and
>>> mutating methods differently, but would these represent the same explicit
>>> “I know that what I’m doing here will have side-effects” impact (especially
>>> if other IDEs add Swift support but don’t do this).
>>>
>>> > On 22 Apr 2016, at 11:54, Vladimir.S via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>> >
>>> > From one point of view, it will be really awesome if we'll have some
>>> kind of 'marker' for mutating methods so we can clearly see in code if that
>>> method changes the instance(just like we all agree that we must specify &
>>> for inout parameter).
>>> >
>>> > From other point of view, this will add a much more noise(and typing)
>>> in code as we often(in most cases?) use mutating methods. Have a code with
>>> a huge number of & symbols(or other) in it - not the best thing.
>>> >
>>> > I don't see how we can unite both points.
>>> >
>>> > On 22.04.2016 10:00, Tyler Cloutier via swift-evolution wrote:
>>> >> If I recall correctly there was a thread with a similar idea which
>>> instead
>>> >> would create a new operator for mutation or a new way of method
>>> invocation,
>>> >> such that mutating methods would be called with &. or something
>>> similar. e.g.
>>> >>
>>> >> foo&.add(5)
>>> >>
>>> >> I think the consensus was that that was not a particularly familiar
>>> syntax
>>> >> and it would add a decent amount of noise.
>>> >>
>>> >> There may have also been some issues with the grammar, I can't recall.
>>> >>
>>> >> On Apr 21, 2016, at 11:40 PM, Krishna Kumar via swift-evolution
>>> >> > wrote:
>>> >>
>>> >>> Hey
>>> >>>
>>> >>> I think adding “&” to methods will reduce the readability of the
>>> code.
>>> >>> Also, keyword “mutating” makes it super clear and readable that my
>>> method
>>> >>> is mutating the values.
>>> >>>
>>> >>> 1. mutating func add(value: Double){…}
>>> >>>
>>> >>> 2. func add&(value: Double){…}
>>> >>>
>>> >>> I think it’s easy to skip the information encoded into the 2nd
>>> function
>>> >>> which is this function is mutating a value as compared to 1st. When I
>>> >>> read 1st function I start reading with keyword “mutating” making its
>>> >>> intentions clear to me.
>>> >>>
>>> >>> Also, it might become a symbol nightmare with following type
>>> signature of
>>> >>> a function-
>>> >>>
>>> >>> func nightmare&(title: String?) -> String? -> String?{…}
>>> >>>
>>> >>> I can see the advantage of using “&” when calling a function. It
>>> makes
>>> >>> clear at the call site that this method is mutating but still I don’t
>>> >>> find eliminating “mutating” a good 

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

[Patrick Smith via swift-evolution]

Well, you could actually have something like this now, and use whether the 
returned result was used or not to know if was a mutating or nonmutating method 
or not.

Patrick




On Fri, Apr 22, 2016 at 4:53 AM -0700, "James Campbell via swift-evolution" 
 wrote:










What if we had a concept similar to errors and try ? 
Given this function:
func sort() -> Self {}
mutating sort() -> Self {}

If a developer calls:
array.sort()
It will sort a copy of that array, in order to sort in place the developer must 
confirm the mutation like so:
mutate array.sort()
This will then call the mutating version of sort :)










___

James⎥Chief Of Fun

ja...@supmenow.com⎥supmenow.com

Sup

Runway East


10 Finsbury Square

London


EC2A 1AF 

On 22 April 2016 at 12:31, Haravikk via swift-evolution 
 wrote:
This is why I mentioned Xcode; while we can have ampersand as a language 
feature for marking such things explicitly (i.e- developer consents to doing 
it), we could also just have Xcode highlight inout parameters and mutating 
methods differently, but would these represent the same explicit “I know that 
what I’m doing here will have side-effects” impact (especially if other IDEs 
add Swift support but don’t do this).



> On 22 Apr 2016, at 11:54, Vladimir.S via swift-evolution 
>  wrote:

>

> From one point of view, it will be really awesome if we'll have some kind of 
> 'marker' for mutating methods so we can clearly see in code if that method 
> changes the instance(just like we all agree that we must specify & for inout 
> parameter).

>

> From other point of view, this will add a much more noise(and typing) in code 
> as we often(in most cases?) use mutating methods. Have a code with a huge 
> number of & symbols(or other) in it - not the best thing.

>

> I don't see how we can unite both points.

>

> On 22.04.2016 10:00, Tyler Cloutier via swift-evolution wrote:

>> If I recall correctly there was a thread with a similar idea which instead

>> would create a new operator for mutation or a new way of method invocation,

>> such that mutating methods would be called with &. or something similar. e.g.

>>

>> foo&.add(5)

>>

>> I think the consensus was that that was not a particularly familiar syntax

>> and it would add a decent amount of noise.

>>

>> There may have also been some issues with the grammar, I can't recall.

>>

>> On Apr 21, 2016, at 11:40 PM, Krishna Kumar via swift-evolution

>> > wrote:

>>

>>> Hey

>>>

>>> I think adding “&” to methods will reduce the readability of the code.

>>> Also, keyword “mutating” makes it super clear and readable that my method

>>> is mutating the values.

>>>

>>> 1. mutating func add(value: Double){…}

>>>

>>> 2. func add&(value: Double){…}

>>>

>>> I think it’s easy to skip the information encoded into the 2nd function

>>> which is this function is mutating a value as compared to 1st. When I

>>> read 1st function I start reading with keyword “mutating” making its

>>> intentions clear to me.

>>>

>>> Also, it might become a symbol nightmare with following type signature of

>>> a function-

>>>

>>> func nightmare&(title: String?) -> String? -> String?{…}

>>>

>>> I can see the advantage of using “&” when calling a function. It makes

>>> clear at the call site that this method is mutating but still I don’t

>>> find eliminating “mutating” a good step for the reasons mentioned above.

>>>

>>> Maybe we can think of some better solution.

>>>

>>> Thanks

>>>

>>> -Krishna

>>>

 On Apr 21, 2016, at 10:38 PM, Daniel Steinberg via swift-evolution

 > wrote:



 swift-evolution@swift.org 

>>>

>>> ___

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

>>

> ___

> 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








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

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

[James Campbell via swift-evolution]

What if we had a concept similar to errors and try ?

Given this function:

func sort() -> Self {
}

mutating sort() -> Self {
}


If a developer calls:

array.sort()

It will sort a copy of that array, in order to sort in place the developer
must confirm the mutation like so:

mutate array.sort()

This will then call the mutating version of sort :)

*___*

*James⎥Chief Of Fun*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 22 April 2016 at 12:31, Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

> This is why I mentioned Xcode; while we can have ampersand as a language
> feature for marking such things explicitly (i.e- developer consents to
> doing it), we could also just have Xcode highlight inout parameters and
> mutating methods differently, but would these represent the same explicit
> “I know that what I’m doing here will have side-effects” impact (especially
> if other IDEs add Swift support but don’t do this).
>
> > On 22 Apr 2016, at 11:54, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > From one point of view, it will be really awesome if we'll have some
> kind of 'marker' for mutating methods so we can clearly see in code if that
> method changes the instance(just like we all agree that we must specify &
> for inout parameter).
> >
> > From other point of view, this will add a much more noise(and typing) in
> code as we often(in most cases?) use mutating methods. Have a code with a
> huge number of & symbols(or other) in it - not the best thing.
> >
> > I don't see how we can unite both points.
> >
> > On 22.04.2016 10:00, Tyler Cloutier via swift-evolution wrote:
> >> If I recall correctly there was a thread with a similar idea which
> instead
> >> would create a new operator for mutation or a new way of method
> invocation,
> >> such that mutating methods would be called with &. or something
> similar. e.g.
> >>
> >> foo&.add(5)
> >>
> >> I think the consensus was that that was not a particularly familiar
> syntax
> >> and it would add a decent amount of noise.
> >>
> >> There may have also been some issues with the grammar, I can't recall.
> >>
> >> On Apr 21, 2016, at 11:40 PM, Krishna Kumar via swift-evolution
> >> > wrote:
> >>
> >>> Hey
> >>>
> >>> I think adding “&” to methods will reduce the readability of the code.
> >>> Also, keyword “mutating” makes it super clear and readable that my
> method
> >>> is mutating the values.
> >>>
> >>> 1. mutating func add(value: Double){…}
> >>>
> >>> 2. func add&(value: Double){…}
> >>>
> >>> I think it’s easy to skip the information encoded into the 2nd function
> >>> which is this function is mutating a value as compared to 1st. When I
> >>> read 1st function I start reading with keyword “mutating” making its
> >>> intentions clear to me.
> >>>
> >>> Also, it might become a symbol nightmare with following type signature
> of
> >>> a function-
> >>>
> >>> func nightmare&(title: String?) -> String? -> String?{…}
> >>>
> >>> I can see the advantage of using “&” when calling a function. It makes
> >>> clear at the call site that this method is mutating but still I don’t
> >>> find eliminating “mutating” a good step for the reasons mentioned
> above.
> >>>
> >>> Maybe we can think of some better solution.
> >>>
> >>> Thanks
> >>>
> >>> -Krishna
> >>>
>  On Apr 21, 2016, at 10:38 PM, Daniel Steinberg via swift-evolution
>  > wrote:
> 
>  swift-evolution@swift.org 
> >>>
> >>> ___
> >>> 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
> >>
> > ___
> > 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

This is why I mentioned Xcode; while we can have ampersand as a language 
feature for marking such things explicitly (i.e- developer consents to doing 
it), we could also just have Xcode highlight inout parameters and mutating 
methods differently, but would these represent the same explicit “I know that 
what I’m doing here will have side-effects” impact (especially if other IDEs 
add Swift support but don’t do this).

> On 22 Apr 2016, at 11:54, Vladimir.S via swift-evolution 
>  wrote:
> 
> From one point of view, it will be really awesome if we'll have some kind of 
> 'marker' for mutating methods so we can clearly see in code if that method 
> changes the instance(just like we all agree that we must specify & for inout 
> parameter).
> 
> From other point of view, this will add a much more noise(and typing) in code 
> as we often(in most cases?) use mutating methods. Have a code with a huge 
> number of & symbols(or other) in it - not the best thing.
> 
> I don't see how we can unite both points.
> 
> On 22.04.2016 10:00, Tyler Cloutier via swift-evolution wrote:
>> If I recall correctly there was a thread with a similar idea which instead
>> would create a new operator for mutation or a new way of method invocation,
>> such that mutating methods would be called with &. or something similar. e.g.
>> 
>> foo&.add(5)
>> 
>> I think the consensus was that that was not a particularly familiar syntax
>> and it would add a decent amount of noise.
>> 
>> There may have also been some issues with the grammar, I can't recall.
>> 
>> On Apr 21, 2016, at 11:40 PM, Krishna Kumar via swift-evolution
>> > wrote:
>> 
>>> Hey
>>> 
>>> I think adding “&” to methods will reduce the readability of the code.
>>> Also, keyword “mutating” makes it super clear and readable that my method
>>> is mutating the values.
>>> 
>>> 1. mutating func add(value: Double){…}
>>> 
>>> 2. func add&(value: Double){…}
>>> 
>>> I think it’s easy to skip the information encoded into the 2nd function
>>> which is this function is mutating a value as compared to 1st. When I
>>> read 1st function I start reading with keyword “mutating” making its
>>> intentions clear to me.
>>> 
>>> Also, it might become a symbol nightmare with following type signature of
>>> a function-
>>> 
>>> func nightmare&(title: String?) -> String? -> String?{…}
>>> 
>>> I can see the advantage of using “&” when calling a function. It makes
>>> clear at the call site that this method is mutating but still I don’t
>>> find eliminating “mutating” a good step for the reasons mentioned above.
>>> 
>>> Maybe we can think of some better solution.
>>> 
>>> Thanks
>>> 
>>> -Krishna
>>> 
 On Apr 21, 2016, at 10:38 PM, Daniel Steinberg via swift-evolution
 > wrote:
 
 swift-evolution@swift.org 
>>> 
>>> ___
>>> 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
>> 
> ___
> 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

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

[Vladimir.S via swift-evolution]

From one point of view, it will be really awesome if we'll have some kind 
of 'marker' for mutating methods so we can clearly see in code if that 
method changes the instance(just like we all agree that we must specify & 
for inout parameter).


From other point of view, this will add a much more noise(and typing) in 
code as we often(in most cases?) use mutating methods. Have a code with a 
huge number of & symbols(or other) in it - not the best thing.


I don't see how we can unite both points.

On 22.04.2016 10:00, Tyler Cloutier via swift-evolution wrote:

If I recall correctly there was a thread with a similar idea which instead
would create a new operator for mutation or a new way of method invocation,
such that mutating methods would be called with &. or something similar. e.g.

foo&.add(5)

I think the consensus was that that was not a particularly familiar syntax
and it would add a decent amount of noise.

There may have also been some issues with the grammar, I can't recall.

On Apr 21, 2016, at 11:40 PM, Krishna Kumar via swift-evolution
> wrote:


Hey

I think adding “&” to methods will reduce the readability of the code.
Also, keyword “mutating” makes it super clear and readable that my method
is mutating the values.

1. mutating func add(value: Double){…}

2. func add&(value: Double){…}

I think it’s easy to skip the information encoded into the 2nd function
which is this function is mutating a value as compared to 1st. When I
read 1st function I start reading with keyword “mutating” making its
intentions clear to me.

Also, it might become a symbol nightmare with following type signature of
a function-

func nightmare&(title: String?) -> String? -> String?{…}

I can see the advantage of using “&” when calling a function. It makes
clear at the call site that this method is mutating but still I don’t
find eliminating “mutating” a good step for the reasons mentioned above.

Maybe we can think of some better solution.

Thanks

-Krishna


On Apr 21, 2016, at 10:38 PM, Daniel Steinberg via swift-evolution
> wrote:

swift-evolution@swift.org 


___
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


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

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

[Haravikk via swift-evolution]

I think that Swift has this fairly well covered so long as your mutating 
methods don’t need to return anything, as the type system will handle that, 
while @warn_unused_result (which I think is becoming the default on methods 
with return types?) will cover the non-mutating cases. The only place where it 
gets awkward is if a mutating method needs to return something, but the name of 
the method should ideally be something clear in such cases.

Basically I think that as long as type-checking/unused result checking and a 
clear naming scheme solve the problem there should be no need for a custom 
syntax.


Aside from that I think that is something that an Xcode feature could solve; 
for example if mutating methods were coloured differently from non-mutating 
ones.

> On 21 Apr 2016, at 18:08, Daniel Steinberg via swift-evolution 
>  wrote:
> 
> Pardon me if this has been raised before.
> 
> I gave a short presentation at our Cleveland CocoaHeads this week on what is 
> coming in Swift 3. One of the attendees stayed behind to ask about the naming 
> guidelines for mutating vs non-mutating. He is fairly new to Swift - coming 
> from Ruby. I have no Ruby experience but am passing his thoughts on to this 
> list.
> 
> He said that in Ruby they decorate the name with a symbol (I believe in their 
> case it is “!”) to distinguish between the two. Although usually I’m not a 
> fan of such naming conventions, we do something similar with inout parameters.
> 
> For example, if we have
> 
> func myFunc(param: inout String) { …}
> 
> we call it like this (using the Swift 3 first label convention)
> 
> myFunc(param: )
> 
> We use the & to signal that the value of aName might be changed by the call 
> to myFunc().
> 
> Similarly, instead of settling on a naming convention for verb vs 
> verbed/verbing we could name the methods descriptively and require a symbol 
> (here I use & but only for illustration) to distinguish between mutating and 
> non-mutating
> 
> so we would have 
> 
> myArray.sort&()
> 
> and
> 
> sortedArray = myArray.sort()
> 
> Xcode and other tools could enforce this naming pattern and warn us that a 
> mutating method must end in “&” and that a non-mutating method is not allowed 
> to.
> 
> Best,
> 
> Daniel
> ___
> 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

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

[Haravikk via swift-evolution]

I think that Swift has this fairly well covered so long as your mutating 
methods don’t need to return anything, as the type system will handle that, 
while @warn_unused_result (which I think is becoming the default on methods 
with return types?) will cover the non-mutating cases. The only place where it 
gets awkward is if a mutating method needs to return something, but the name of 
the method should ideally be something clear in such cases.

Basically I think that as long as type-checking/unused result checking and a 
clear naming scheme solve the problem there should be no need for a custom 
syntax.


Aside from that I think that is something that an Xcode feature could solve; 
for example if mutating methods were coloured differently from non-mutating 
ones.

> On 21 Apr 2016, at 18:08, Daniel Steinberg via swift-evolution 
>  wrote:
> 
> Pardon me if this has been raised before.
> 
> I gave a short presentation at our Cleveland CocoaHeads this week on what is 
> coming in Swift 3. One of the attendees stayed behind to ask about the naming 
> guidelines for mutating vs non-mutating. He is fairly new to Swift - coming 
> from Ruby. I have no Ruby experience but am passing his thoughts on to this 
> list.
> 
> He said that in Ruby they decorate the name with a symbol (I believe in their 
> case it is “!”) to distinguish between the two. Although usually I’m not a 
> fan of such naming conventions, we do something similar with inout parameters.
> 
> For example, if we have
> 
> func myFunc(param: inout String) { …}
> 
> we call it like this (using the Swift 3 first label convention)
> 
> myFunc(param: )
> 
> We use the & to signal that the value of aName might be changed by the call 
> to myFunc().
> 
> Similarly, instead of settling on a naming convention for verb vs 
> verbed/verbing we could name the methods descriptively and require a symbol 
> (here I use & but only for illustration) to distinguish between mutating and 
> non-mutating
> 
> so we would have 
> 
> myArray.sort&()
> 
> and
> 
> sortedArray = myArray.sort()
> 
> Xcode and other tools could enforce this naming pattern and warn us that a 
> mutating method must end in “&” and that a non-mutating method is not allowed 
> to.
> 
> Best,
> 
> Daniel
> ___
> 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

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

[Daniel Steinberg via swift-evolution]

Sorry I left mutating off by mistake. I'm referring to the call site more

> On Apr 22, 2016, at 8:40 AM, Krishna Kumar  wrote:
> 
> Hey
> 
> I think adding “&” to methods will reduce the readability of the code. Also, 
> keyword “mutating” makes it super clear and readable that my method is 
> mutating the values.
> 
> 1. mutating func add(value: Double){…}
> 
> 2. func add&(value: Double){…}
> 
> I think it’s easy to skip the information encoded into the 2nd function which 
> is this function is mutating a value as compared to 1st. When I read 1st 
> function I start reading with keyword “mutating” making its intentions clear 
> to me.
> 
> Also, it might become a symbol nightmare with following type signature of a 
> function-
> 
> func nightmare&(title: String?) -> String? -> String?{…}
> 
> I can see the advantage of using “&” when calling a function. It makes clear 
> at the call site that this method is mutating but still I don’t find 
> eliminating “mutating” a good step for the reasons mentioned above.
> 
> Maybe we can think of some better solution.
> 
> Thanks
> 
> -Krishna
> 
>> On Apr 21, 2016, at 10:38 PM, Daniel Steinberg via swift-evolution 
>>  wrote:
>> 
>> swift-evolution@swift.org
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tyler Cloutier via swift-evolution]

That being said I try to follow most of the discussions on swift-evolution and 
there does seem to be a great deal of hand wringing regarding this and things 
related to or affected by this.

> On Apr 22, 2016, at 12:00 AM, Tyler Cloutier via swift-evolution 
>  wrote:
> 
> If I recall correctly there was a thread with a similar idea which instead 
> would create a new operator for mutation or a new way of method invocation, 
> such that mutating methods would be called with &. or something similar. e.g.
> 
> foo&.add(5)
> 
> I think the consensus was that that was not a particularly familiar syntax 
> and it would add a decent amount of noise.
> 
> There may have also been some issues with the grammar, I can't recall.
> 
>> On Apr 21, 2016, at 11:40 PM, Krishna Kumar via swift-evolution 
>>  wrote:
>> 
>> Hey
>> 
>> I think adding “&” to methods will reduce the readability of the code. Also, 
>> keyword “mutating” makes it super clear and readable that my method is 
>> mutating the values.
>> 
>> 1. mutating func add(value: Double){…}
>> 
>> 2. func add&(value: Double){…}
>> 
>> I think it’s easy to skip the information encoded into the 2nd function 
>> which is this function is mutating a value as compared to 1st. When I read 
>> 1st function I start reading with keyword “mutating” making its intentions 
>> clear to me.
>> 
>> Also, it might become a symbol nightmare with following type signature of a 
>> function-
>> 
>> func nightmare&(title: String?) -> String? -> String?{…}
>> 
>> I can see the advantage of using “&” when calling a function. It makes clear 
>> at the call site that this method is mutating but still I don’t find 
>> eliminating “mutating” a good step for the reasons mentioned above.
>> 
>> Maybe we can think of some better solution.
>> 
>> Thanks
>> 
>> -Krishna
>> 
>>> On Apr 21, 2016, at 10:38 PM, Daniel Steinberg via swift-evolution 
>>>  wrote:
>>> 
>>> swift-evolution@swift.org
>> 
>> ___
>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tyler Cloutier via swift-evolution]

If I recall correctly there was a thread with a similar idea which instead 
would create a new operator for mutation or a new way of method invocation, 
such that mutating methods would be called with &. or something similar. e.g.

foo&.add(5)

I think the consensus was that that was not a particularly familiar syntax and 
it would add a decent amount of noise.

There may have also been some issues with the grammar, I can't recall.

> On Apr 21, 2016, at 11:40 PM, Krishna Kumar via swift-evolution 
>  wrote:
> 
> Hey
> 
> I think adding “&” to methods will reduce the readability of the code. Also, 
> keyword “mutating” makes it super clear and readable that my method is 
> mutating the values.
> 
> 1. mutating func add(value: Double){…}
> 
> 2. func add&(value: Double){…}
> 
> I think it’s easy to skip the information encoded into the 2nd function which 
> is this function is mutating a value as compared to 1st. When I read 1st 
> function I start reading with keyword “mutating” making its intentions clear 
> to me.
> 
> Also, it might become a symbol nightmare with following type signature of a 
> function-
> 
> func nightmare&(title: String?) -> String? -> String?{…}
> 
> I can see the advantage of using “&” when calling a function. It makes clear 
> at the call site that this method is mutating but still I don’t find 
> eliminating “mutating” a good step for the reasons mentioned above.
> 
> Maybe we can think of some better solution.
> 
> Thanks
> 
> -Krishna
> 
>> On Apr 21, 2016, at 10:38 PM, Daniel Steinberg via swift-evolution 
>>  wrote:
>> 
>> swift-evolution@swift.org
> 
> ___
> 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

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

[Krishna Kumar via swift-evolution]

Hey

I think adding “&” to methods will reduce the readability of the code. Also, 
keyword “mutating” makes it super clear and readable that my method is mutating 
the values.

1. mutating func add(value: Double){…}

2. func add&(value: Double){…}

I think it’s easy to skip the information encoded into the 2nd function which 
is this function is mutating a value as compared to 1st. When I read 1st 
function I start reading with keyword “mutating” making its intentions clear to 
me.

Also, it might become a symbol nightmare with following type signature of a 
function-

func nightmare&(title: String?) -> String? -> String?{…}

I can see the advantage of using “&” when calling a function. It makes clear at 
the call site that this method is mutating but still I don’t find eliminating 
“mutating” a good step for the reasons mentioned above.

Maybe we can think of some better solution.

Thanks

-Krishna

> On Apr 21, 2016, at 10:38 PM, Daniel Steinberg via swift-evolution 
>  wrote:
> 
> swift-evolution@swift.org 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Daniel Steinberg via swift-evolution]

Pardon me if this has been raised before.

I gave a short presentation at our Cleveland CocoaHeads this week on what is 
coming in Swift 3. One of the attendees stayed behind to ask about the naming 
guidelines for mutating vs non-mutating. He is fairly new to Swift - coming 
from Ruby. I have no Ruby experience but am passing his thoughts on to this 
list.

He said that in Ruby they decorate the name with a symbol (I believe in their 
case it is “!”) to distinguish between the two. Although usually I’m not a fan 
of such naming conventions, we do something similar with inout parameters.

For example, if we have

func myFunc(param: inout String) { …}

we call it like this (using the Swift 3 first label convention)

myFunc(param: )

We use the & to signal that the value of aName might be changed by the call to 
myFunc().

Similarly, instead of settling on a naming convention for verb vs 
verbed/verbing we could name the methods descriptively and require a symbol 
(here I use & but only for illustration) to distinguish between mutating and 
non-mutating

so we would have 

myArray.sort&()

and

sortedArray = myArray.sort()

Xcode and other tools could enforce this naming pattern and warn us that a 
mutating method must end in “&” and that a non-mutating method is not allowed 
to.

Best,

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