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

[Vladimir.S]

[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.
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.
>