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

[Patrick Smith]

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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160424/97812291/attachment.html>