[Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

It is, but x.doUnion(y) doesn't make any plausible sense, at least not
to me.

···

on Mon Apr 04 2016, Xiaodi Wu <swift-evolution@swift.org> wrote:

My read on the API guidelines is that the mutating/non-mutating distinction is
made by verbs vs. nouns. The verb itself doesn't have to "suggest" or "feel"
mutating, it just has to be clearly a verb. Thus, IMO, `form` is as good a verb
as any, although if we're going to return to bikeshedding I would suggest that
`do` is even shorter.

--
Dave

Hmm, "emplace" looks like more or less a synonym for "install." I
don't think it suggests that the object is being put in place of the
subject.

It’s roughly a synonym. “emplaceUnion” is "putting the union into position". There is no other position than “self”.

The latest example in the Oxford English Dictionary, from
2010, is:
"Insurgents would hastily emplace victim-activated IEDs...after
Pathfinder came through."
Here, the IEDs are not taking the place of the insurgents.

I was going to comment about your choice of a terrorism-related example sentence, but the online OED *only* uses war-related examples for this verb.

  - Doug

···

On Apr 4, 2016, at 9:20 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Mon, Apr 4, 2016 at 11:14 AM, Douglas Gregor via swift-evolution > <swift-evolution@swift.org> wrote:

On Apr 3, 2016, at 1:56 PM, Shawn Erickson <shawnce@gmail.com> wrote:

On Sun, Apr 3, 2016 at 1:27 PM Shawn Erickson <shawnce@gmail.com> wrote:

On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution >>> <swift-evolution@swift.org> wrote:

What is your evaluation of the proposal?

I don't like "form" as a prefix. To me there is no difference between
`union` and `formUnion`: both sounds functional-style, and actually the
second one perhaps a bit more to my ears. There's basically two dictionary
definitions of "form":

1. "bring together parts or combine to create (something)" which to me
implies a new value is created, and
2. "make or fashion into a certain shape or form" which would imply that
the material you start with is transformed, which is apparently the intended
meaning and also the reverse meaning from the above.

I mean, doesn't this make sense as an API?

       let donut = baker.formDonut(dough) // non-mutating

Perhaps instead of "form" we could use "become" as a prefix when the
operation is naturally described by a noun. That would seem less ambiguous
to me:

       a.becomeUnion(b)
       a.becomeIntersection(b)
       a.becomeSuccessor(b)

It's a bit passive, but I find it fits well when the operation is a noun.

And there's no way the term lends itself to non-mutating cases without
things becoming nonsensical:

       let donut = baker.becomeDonut(dough) // non-mutating?

I also am having difficulty coming to terms with the use of "form" (I am a
native English speaker). As you note "form" can imply the creation of
something from parts (more like assembling a new thing) as well as the
creation of something out of a material say a of block clay (more like
molding something out of an existing thing). It doesn't seem clear cut to me
to imply in place mutation.

Additionally my eyes / brain keep seeing "from" instead of "form". This
type of issue is generally true with any short word made up of the same set
of letters (made worse since "from" is more common in programming then
"form"). The mind quickly narrows in on a set of possible words given the
letters we see and then uses context to help get the correct one and/or
additional visual parsing to understand the exact ordering of letters (more
energy expended). Anyway since I keep seeing "from" instead of "form" I keep
going in the direction of thinking it returns something made from the two
(or more) items involved (not really sure why "from" goes that direction in
my head, it could also go the in place direction).

I would prefer something other then "form" (note I just typed "from" by
mistake)... I think your suggestion of "become" has merit.

y.becomeUnion(x) --reads to me as--> "y become union with x"
y.formUnion(x) --read to me as--> "y from oops... y forming a union of x"
y.becomeIntersection(x) --reads to me as--> "y become intersection with x"
y.formIntersection(x) --read to me as--> "y from oops... y forming an
intersection with x"

After stepping away for a bit and looking at it from the POV of the API of
Set and not in the context of "y" I could read things in the abstract as...

"becomeUnion(with other:Self)" --> "I become a union with other"
"formUnion(with other:Self)" --> "I form a union with other"

No clear winner to me however when used in code "become" still feels more
strongly mutating then "form": y.formUnion(with:x) or y.becomeUnion(with:x)

All in all the API would have mutating in front of it (at least for structs)
and it wouldn't have a return type. It would become clear fairly quickly as
a result (hence learned).

Just still not that happy with "form" but with use my mind would likely
quickly adapt.

I think the best English verb for this construction is “emplace”:

EMPLACE Definition & Usage Examples | Dictionary.com

It means “to put in position”, and is always used with an object (the noun).
It’s basically free from incorrect connotations because it’s obscure enough
that most English speakers won’t know it, and is easily searchable for
English- and non-English speakers alike.

- Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Indeed, OED points out that modern usage is "chiefly military." Probably an
argument against its usage here.

···

On Mon, Apr 4, 2016 at 12:09 PM Douglas Gregor <dgregor@apple.com> wrote:

> On Apr 4, 2016, at 9:20 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
>
> Hmm, "emplace" looks like more or less a synonym for "install." I
> don't think it suggests that the object is being put in place of the
> subject.

It’s roughly a synonym. “emplaceUnion” is "putting the union into
position". There is no other position than “self”.

> The latest example in the Oxford English Dictionary, from
> 2010, is:
> "Insurgents would hastily emplace victim-activated IEDs...after
> Pathfinder came through."
> Here, the IEDs are not taking the place of the insurgents.

I was going to comment about your choice of a terrorism-related example
sentence, but the online OED *only* uses war-related examples for this verb.

        - Doug

>
> On Mon, Apr 4, 2016 at 11:14 AM, Douglas Gregor via swift-evolution > > <swift-evolution@swift.org> wrote:
>>
>> On Apr 3, 2016, at 1:56 PM, Shawn Erickson <shawnce@gmail.com> wrote:
>>
>>
>>
>> On Sun, Apr 3, 2016 at 1:27 PM Shawn Erickson <shawnce@gmail.com> > wrote:
>>>
>>> On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution > >>> <swift-evolution@swift.org> wrote:
>>>>
>>>>> What is your evaluation of the proposal?
>>>>
>>>> I don't like "form" as a prefix. To me there is no difference between
>>>> `union` and `formUnion`: both sounds functional-style, and actually
the
>>>> second one perhaps a bit more to my ears. There's basically two
dictionary
>>>> definitions of "form":
>>>>
>>>> 1. "bring together parts or combine to create (something)" which to me
>>>> implies a new value is created, and
>>>> 2. "make or fashion into a certain shape or form" which would imply
that
>>>> the material you start with is transformed, which is apparently the
intended
>>>> meaning and also the reverse meaning from the above.
>>>>
>>>> I mean, doesn't this make sense as an API?
>>>>
>>>> let donut = baker.formDonut(dough) // non-mutating
>>>>
>>>> Perhaps instead of "form" we could use "become" as a prefix when the
>>>> operation is naturally described by a noun. That would seem less
ambiguous
>>>> to me:
>>>>
>>>> a.becomeUnion(b)
>>>> a.becomeIntersection(b)
>>>> a.becomeSuccessor(b)
>>>>
>>>> It's a bit passive, but I find it fits well when the operation is a
noun.
>>>>
>>>> And there's no way the term lends itself to non-mutating cases without
>>>> things becoming nonsensical:
>>>>
>>>> let donut = baker.becomeDonut(dough) // non-mutating?
>>>
>>>
>>> I also am having difficulty coming to terms with the use of "form" (I
am a
>>> native English speaker). As you note "form" can imply the creation of
>>> something from parts (more like assembling a new thing) as well as the
>>> creation of something out of a material say a of block clay (more like
>>> molding something out of an existing thing). It doesn't seem clear cut
to me
>>> to imply in place mutation.
>>>
>>> Additionally my eyes / brain keep seeing "from" instead of "form". This
>>> type of issue is generally true with any short word made up of the
same set
>>> of letters (made worse since "from" is more common in programming then
>>> "form"). The mind quickly narrows in on a set of possible words given
the
>>> letters we see and then uses context to help get the correct one and/or
>>> additional visual parsing to understand the exact ordering of letters
(more
>>> energy expended). Anyway since I keep seeing "from" instead of "form"
I keep
>>> going in the direction of thinking it returns something made from the
two
>>> (or more) items involved (not really sure why "from" goes that
direction in
>>> my head, it could also go the in place direction).
>>>
>>> I would prefer something other then "form" (note I just typed "from" by
>>> mistake)... I think your suggestion of "become" has merit.
>>>
>>> y.becomeUnion(x) --reads to me as--> "y become union with x"
>>> y.formUnion(x) --read to me as--> "y from oops... y forming a union of
x"
>>> y.becomeIntersection(x) --reads to me as--> "y become intersection
with x"
>>> y.formIntersection(x) --read to me as--> "y from oops... y forming an
>>> intersection with x"
>>
>>
>> After stepping away for a bit and looking at it from the POV of the API
of
>> Set and not in the context of "y" I could read things in the abstract
as...
>>
>> "becomeUnion(with other:Self)" --> "I become a union with other"
>> "formUnion(with other:Self)" --> "I form a union with other"
>>
>> No clear winner to me however when used in code "become" still feels
more
>> strongly mutating then "form": y.formUnion(with:x) or
y.becomeUnion(with:x)
>>
>> All in all the API would have mutating in front of it (at least for
structs)
>> and it wouldn't have a return type. It would become clear fairly
quickly as
>> a result (hence learned).
>>
>> Just still not that happy with "form" but with use my mind would likely
>> quickly adapt.
>>
>>
>> I think the best English verb for this construction is “emplace”:
>>
>> EMPLACE Definition & Usage Examples | Dictionary.com
>>
>> It means “to put in position”, and is always used with an object (the
noun).
>> It’s basically free from incorrect connotations because it’s obscure
enough
>> that most English speakers won’t know it, and is easily searchable for
>> English- and non-English speakers alike.
>>
>> - Doug
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>

It's worth mentioning that there's still a fanbase for `union` and `unionInPlace`.

-- E

···

On Apr 7, 2016, at 2:34 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Mon Apr 04 2016, Xiaodi Wu <swift-evolution@swift.org> wrote:

My read on the API guidelines is that the mutating/non-mutating distinction is
made by verbs vs. nouns. The verb itself doesn't have to "suggest" or "feel"
mutating, it just has to be clearly a verb. Thus, IMO, `form` is as good a verb
as any, although if we're going to return to bikeshedding I would suggest that
`do` is even shorter.

It is, but x.doUnion(y) doesn't make any plausible sense, at least not
to me.

Indeed, OED points out that modern usage is "chiefly military." Probably an argument against its usage here.

It seems to me that what you're sort of saying is "replaceWith", but that's kind of a mouthful. A quick thesaurus check suggests that the only decent single-world alternative would be "substitute", but that sounds like a regex operation. I think this is a dead end.

···

--
Brent Royal-Gordon
Architechies

This has been a very long and complex thread, but have some of these
not-technically-mathy word pairs that have nice verb forms been
considered:

union -> combine / combining
intersection -> intersect / intersecting
symmetricDifference -> split / splitting

Yes, some of them have been considered.

···

on Mon Apr 04 2016, Sean Heber <swift-evolution@swift.org> wrote:

Example:

var allowedUsers = Set<User>()
allowedUsers.combine(standardUsers)
allowedUsers.combine(superUsers)

var users = allUsers
users.intersect(allowedUsers)

let users = allUsers.intersecting(allowedUsers)

l8r
Sean

On Apr 4, 2016, at 3:22 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Indeed, OED points out that modern usage is "chiefly military." Probably an argument against its usage here.

It seems to me that what you're sort of saying is "replaceWith", but
that's kind of a mouthful. A quick thesaurus check suggests that the
only decent single-world alternative would be "substitute", but that
sounds like a regex operation. I think this is a dead end.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave

This has been a very long and complex thread, but have some of these not-technically-mathy word pairs that have nice verb forms been considered:

union -> combine / combining
intersection -> intersect / intersecting
symmetricDifference -> split / splitting

Example:

var allowedUsers = Set<User>()
allowedUsers.combine(standardUsers)
allowedUsers.combine(superUsers)

var users = allUsers
users.intersect(allowedUsers)

let users = allUsers.intersecting(allowedUsers)

l8r
Sean

···

On Apr 4, 2016, at 3:22 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Indeed, OED points out that modern usage is "chiefly military." Probably an argument against its usage here.

It seems to me that what you're sort of saying is "replaceWith", but that's kind of a mouthful. A quick thesaurus check suggests that the only decent single-world alternative would be "substitute", but that sounds like a regex operation. I think this is a dead end.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Indeed, OED points out that modern usage is "chiefly military." Probably an argument against its usage here.

It seems to me that what you're sort of saying is "replaceWith", but
that's kind of a mouthful.

It's at least very explicit. We did consider that, and chose “form” as
a more reasonable convention. However, we weren't thinking of the
“from” problem. I prefer “replaceWith” over “become” for some reason I
can't identify.

···

on Mon Apr 04 2016, Brent Royal-Gordon <swift-evolution@swift.org> wrote:

A quick thesaurus check suggests that the only decent single-world
alternative would be "substitute", but that sounds like a regex
operation. I think this is a dead end.

--
Dave

Noted. I'm part of it.

···

on Thu Apr 07 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:

On Apr 7, 2016, at 2:34 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Mon Apr 04 2016, Xiaodi Wu <swift-evolution@swift.org> wrote:

My read on the API guidelines is that the mutating/non-mutating distinction is
made by verbs vs. nouns. The verb itself doesn't have to "suggest" or "feel"
mutating, it just has to be clearly a verb. Thus, IMO, `form` is as good a verb
as any, although if we're going to return to bikeshedding I would suggest that
`do` is even shorter.

It is, but x.doUnion(y) doesn't make any plausible sense, at least not
to me.

It's worth mentioning that there's still a fanbase for `union` and
`unionInPlace`.

--
Dave

replaceWith* is also my favourite here (same for *InPlace). Sure, it might be verbose, but the semantics is very clear and seems apply to a wide range of relevant situations. In the end, there are hundreds if not more messages in this (and related) threads and i am sure that you guys spent even more time in meetings talking about this. If I understand correctly, Swifts goal is clarity over laconicity. If finding sensible laconic terminology turns out to be surprisingly difficult, a more verbose one might be a better choice after all.

— Taras

···

On 07 Apr 2016, at 22:36, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Mon Apr 04 2016, Brent Royal-Gordon <swift-evolution@swift.org> wrote:

Indeed, OED points out that modern usage is "chiefly military." Probably an argument against its usage here.

It seems to me that what you're sort of saying is "replaceWith", but
that's kind of a mouthful.

It's at least very explicit. We did consider that, and chose “form” as
a more reasonable convention. However, we weren't thinking of the
“from” problem. I prefer “replaceWith” over “become” for some reason I
can't identify.

A quick thesaurus check suggests that the only decent single-world
alternative would be "substitute", but that sounds like a regex
operation. I think this is a dead end.

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

If we're going to bikeshed again: how about "assign"?

···

On Thu, Apr 7, 2016 at 7:08 PM Taras Zakharko via swift-evolution < swift-evolution@swift.org> wrote:

replaceWith* is also my favourite here (same for *InPlace). Sure, it might
be verbose, but the semantics is very clear and seems apply to a wide range
of relevant situations. In the end, there are hundreds if not more messages
in this (and related) threads and i am sure that you guys spent even more
time in meetings talking about this. If I understand correctly, Swifts goal
is clarity over laconicity. If finding sensible laconic terminology turns
out to be surprisingly difficult, a more verbose one might be a better
choice after all.

— Taras

> On 07 Apr 2016, at 22:36, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:
>
>
> on Mon Apr 04 2016, Brent Royal-Gordon <swift-evolution@swift.org> > wrote:
>
>>> Indeed, OED points out that modern usage is "chiefly military."
Probably an argument against its usage here.
>>
>> It seems to me that what you're sort of saying is "replaceWith", but
>> that's kind of a mouthful.
>
> It's at least very explicit. We did consider that, and chose “form” as
> a more reasonable convention. However, we weren't thinking of the
> “from” problem. I prefer “replaceWith” over “become” for some reason I
> can't identify.
>
>> A quick thesaurus check suggests that the only decent single-world
>> alternative would be "substitute", but that sounds like a regex
>> operation. I think this is a dead end.
>
> --
> Dave
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

If we're going to bikeshed again: how about "assign"?

It begs for a preposition, which is usually “to,” which has the wrong
meaning :(

···

on Thu Apr 07 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:

On Thu, Apr 7, 2016 at 7:08 PM Taras Zakharko via swift-evolution > <swift-evolution@swift.org> wrote:

    replaceWith* is also my favourite here (same for *InPlace). Sure, it might
    be verbose, but the semantics is very clear and seems apply to a wide range
    of relevant situations. In the end, there are hundreds if not more messages
    in this (and related) threads and i am sure that you guys spent even more
    time in meetings talking about this. If I understand correctly, Swifts goal
    is clarity over laconicity. If finding sensible laconic terminology turns
    out to be surprisingly difficult, a more verbose one might be a better
    choice after all.

    — Taras

    > On 07 Apr 2016, at 22:36, Dave Abrahams via swift-evolution > <swift-evolution@swift.org> wrote:
    >
    >
    > on Mon Apr 04 2016, Brent Royal-Gordon <swift-evolution@swift.org> wrote:
    >
    >>> Indeed, OED points out that modern usage is "chiefly military." Probably
    an argument against its usage here.
    >>
    >> It seems to me that what you're sort of saying is "replaceWith", but
    >> that's kind of a mouthful.
    >
    > It's at least very explicit. We did consider that, and chose “form” as
    > a more reasonable convention. However, we weren't thinking of the
    > “from” problem. I prefer “replaceWith” over “become” for some reason I
    > can't identify.
    >
    >> A quick thesaurus check suggests that the only decent single-world
    >> alternative would be "substitute", but that sounds like a regex
    >> operation. I think this is a dead end.
    >
    > --
    > Dave
    >
    > _______________________________________________
    > swift-evolution mailing list
    > swift-evolution@swift.org
    > https://lists.swift.org/mailman/listinfo/swift-evolution

    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org
    https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave

replaceWith* is also my favourite here (same for *InPlace).

The latter is great because it's a suffix, but it is not as grammatical
as the former. Aside from syntactic weight, I'd say these are about
equal.

Sure, it might be verbose, but the semantics is very clear and seems
apply to a wide range of relevant situations. In the end, there are
hundreds if not more messages in this (and related) threads and i am
sure that you guys spent even more time in meetings talking about
this. If I understand correctly, Swifts goal is clarity over
laconicity. If finding sensible laconic terminology turns out to be
surprisingly difficult, a more verbose one might be a better choice
after all.

I don't think “formXXX” is “not sensible,” even though it may have
disadvantages. If “replaceWithXXX” is an improvement, IMO, it's a
marginal one. “formXXX” actually has one important advantage over
“replaceWithXXX:” the former suggests the true performance nature of the
operation, which is *the* reason you'd choose it over the non-in-place
version, whereas the latter strongly suggests an implementation like
`self = XXX()`.

···

on Thu Apr 07 2016, Taras Zakharko <swift-evolution@swift.org> wrote:

— Taras

On 07 Apr 2016, at 22:36, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Mon Apr 04 2016, Brent Royal-Gordon <swift-evolution@swift.org> wrote:

Indeed, OED points out that modern usage is "chiefly military." Probably an argument against its usage here.

It seems to me that what you're sort of saying is "replaceWith", but
that's kind of a mouthful.

It's at least very explicit. We did consider that, and chose “form” as
a more reasonable convention. However, we weren't thinking of the
“from” problem. I prefer “replaceWith” over “become” for some reason I
can't identify.

A quick thesaurus check suggests that the only decent single-world
alternative would be "substitute", but that sounds like a regex
operation. I think this is a dead end.

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave