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