After hitting Send button, I remembered that "Enhanced floating-point protocols" proposal uses `add`, `subtract`, `multiply` and `divide` names for mutating versions. They should be non-mutating by default, as well as other purely mathematical terms. I don't know how it can be unobvious.
- Anton 2016-04-15 23:36 GMT+03:00 Антон Жилин <[email protected]>: > Thinking about it, `ed`/`ing` and even `form` prefix might not be that bad. > It's more a matter of what should be "default" in a specific domain. > > In imperative domain, mutating version usually feels as the most natural > one. > Think `sort`. Everyone knows that sort must modify the array (usually > through a sequence of swaps) to be most efficient. (Heapsort is an > exception there, I guess.) > That's why it is mutating version should be the shorter one, and > non-mutating should have a prefix or a suffix. > > In functional domain, non-mutating version usually feels as the most > natural one. > Think `filter`, `map`, `reduce`. This functions originated in functional > languages. Functional languages usually have immutability by default. > When we "map" these idioms to Swift, we should let non-mutating version be > the "default" one. > Of course, we can be strict with our own rules and inventive in terms of > function names, but we just shouldn't. > > Think `union`, `intersection`. These terms originated from mathematics, > where mutability just doesn't exist. > Given such a domain area, it should be obvious that `union` on a set means > non-mutating version, unless stated otherwise. > > So, I conclude that we should not enforce any guideline about naming > mutating/non-mutating versions of methods. > Correct me if this is a wrong conclusion. > > - Anton > > 2016-04-15 19:31 GMT+03:00 Erica Sadun <[email protected]>: > >> >> On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution < >> [email protected]> wrote: >> >> I've already expressed these concerns, but nobody noticed, apparently. >> Here is it: >> >> I think current -ed/-ing convention is ugly. It breaks syntactic >> correctness, experience from other languages, mathematical notation and >> functional idioms. >> >> `InPlace` suffix was so far more correct in these terms. We can make >> anything a convention, but should we? >> I liked the proposal about new naming conventions, but overlooked this >> change. >> >> Many people will agree with me. This still can be reviewed until Swift 3. >> If so, I will create a proposal to correct "the big three" in this. >> >> What do you think? >> >> >> I would like to see a formal proposal along these lines. My other >> suggestions are here >> <http://ericasadun.com/2016/04/13/stop-the-madness-and-fix-the-swift-api-guidelines/> >> . >> >> -- E >> >> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
