> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to