[swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Dennis Weissmann]

> On Apr 14, 2016, at 9:00 AM, Vladimir.S via swift-evolution <swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution