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

[Haravikk]

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 <swift-evolution at swift.org> 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: &aName)
> 
> 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution