> On Apr 14, 2016, at 9:00 AM, Vladimir.S via swift-evolution > <[email protected]> wrote: > > [offtopic for "A New Model for Collections and Indices"] > > Just wanted to add my 2 cents to this new naming guidelines proposal that > @Dave pointed to: > "Update API Naming Guidelines and Rewrite Set APIs Accordingly" > https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md > > I strongly feel this "form" prefix is a wrong decision. Is it really most of > us feel this "formXXXX" method name not confusing and think this is a good > solution? Just can't believe in this. > > My mind reads "form" as "from" first. And then, when I re-checked, I see > "fORm". I believe we see "from" much more often than "form" as in code and in > our usual life, so we'll read it as "from" first.
Non-native speaker here, I had/have the exact same problem. Always read “from”. > I have some kind of prove : "I cdn'uolt blveiee taht I cluod aulaclty > uesdnatnrd waht I was rdanieg" > https://en.wikipedia.org/wiki/Typoglycemia > > Additionally, I totally refuse to feel the meaning of "form" word as good > replacement for meaning for "InPlace". InPlace is probably "visually > heavyweight"(as noted in proposal) but IMO much more explicit on what we are > doing and what we'll have in result. > > I have no right now good alternative for "form", and probably the proposal > was already accepted or probably really most of us agree with "form". > > Probably I'll prefer to leave InPlace as in current Swift, or event make it a > suffix(but all lowecased, thinking if we are using "in-place" as one word, > not "in place" as two words): > > y.inplaceUnion(z) > > or probably > > y.assignByUnion(z) > (as we think of this command as > y = y.union(z) > , we can just read it - "y is assigned by the value of y.union(z) " > "assign the variable "name" the value computed by "right_hand_expression"" > => "assign the y the value computer by union(z)" => assignByUnion(z) > for example, first found: > http://www.cs.utah.edu/~germain/PPS/Topics/assignment_statement.html) > > or may be > > y.mutateByUnion(z) > imo clear and explicit. we have 'mutating' when dealing with structs, here is > similar behavior. > > Probably we should rethink the mutating methods at all, and not trying to > find a good word but introduce new syntax in Swift like.. I don't know.. some > kind of y&.union(z) or y$.union(z) or y:union(z) etc. > > Just some opinion. Thank you for reading this. > > [/offtopic] > > On 13.04.2016 21:24, Dave Abrahams via swift-evolution wrote: >>> In other cases, the mutating pair of methods refer to the receiver, not the >>> >argument. >>> > >>> >x = y.union(z) // new value x >>> >y.formUnion(z) // mutates y, not z >>> > >>> >x = y.successor(z) // new value x >>> >y.formSuccessor(z) // mutates z (or replaces), not y >> This is true, but we need a way to deal with these cases as well. >> > _______________________________________________ > 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
