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