On Sun, Apr 24, 2016 at 11:01 AM, Tim Vermeulen via swift-evolution < [email protected]> 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 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. > > > > > > > > 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
