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

I think Michel and Shawn did raise some good points here.

-Thorsten

···

Am 03.04.2016 um 22:27 schrieb Shawn Erickson via swift-evolution <swift-evolution@swift.org>:

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"

In the "forming" situations it – to me – is ambiguous on if that is in place or not. To me it implies more of giving something new back.

I am -1 on "form" aspect of this proposal. ...of course things are learnable as long as things are fairly consistent and not to far out of the norm for typical language use. Personally I don't see "form" as that typical in English.

-Shawn

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

In my opinion these operators would be perfectly appropriate for Sets.
They have exactly the right semantic implications and relationships.
This is the same reason we use + for both scalars and vectors in math,
even though they're different in some ways.

If someone else would like to write a proposal for making these
operators available on sets, I'd support it.

···

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

My apologies if this was previously discussed. Was there ever a
reason given for not using operators for set combiners? That is, | &
- ^ for union, intersection, subtracting, and symmetricDifference,
and |= &= -= ^= for the mutating versions.

With a few exceptions (like `+` for concatenation), Swift doesn't
overload operators to give them different meanings, even if they're
kinda similar if you squint enough.

--
Dave

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

These are all good points.

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"

I don't like its verbosity, but it does solve the "from" problem.

···

on Sun Apr 03 2016, Shawn Erickson <swift-evolution@swift.org> wrote:

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

In the "forming" situations it – to me – is ambiguous on if that is in
place or not. To me it implies more of giving something new back.

I am -1 on "form" aspect of this proposal. ...of course things are
learnable as long as things are fairly consistent and not to far out
of the norm for typical language use. Personally I don't see "form" as
that typical in English.

-Shawn

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

--
Dave

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

  http://www.dictionary.com/browse/emplace

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

···

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 <mailto:shawnce@gmail.com>> wrote:
On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution <swift-evolution@swift.org <mailto: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.

Looking at other languages:

   1. A Java like API would be:
      - mutating func remove(T) -> Void
      - mutating func remove<S: SequenceType ...>(all: S) -> Void
      - func removed(T) -> Self
      - func removed<S...>(all: S) -> Self
      - Similarly for retain and add
      2. In Scala they primarily use operators, so a Scala like API would
   be:
      - func -=(inout Self, T) -> Void
      - func -=<S: SequenceType ...>(inout Self, S) -> Void
      - func -(T) -> Self
      - func -<S...>(all: S) -> Self
      - Similarly for & and +

Either of these naming patterns seems better than those proposed :(.

  -- Howard.

···

On 4 April 2016 at 15:49, Thorsten Seitz via swift-evolution < swift-evolution@swift.org> wrote:

I think Michel and Shawn did raise some good points here.

-Thorsten

Am 03.04.2016 um 22:27 schrieb Shawn Erickson via swift-evolution < > swift-evolution@swift.org>:

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"

In the "forming" situations it – to me – is ambiguous on if that is in
place or not. To me it implies more of giving something new back.

I am -1 on "form" aspect of this proposal. ...of course things are
learnable as long as things are fairly consistent and not to far out of the
norm for typical language use. Personally I don't see "form" as that
typical in English.

-Shawn

_______________________________________________
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

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.

···

On Mon, Apr 4, 2016 at 1:20 AM Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote:

Looking at other languages:

   1. A Java like API would be:
      - mutating func remove(T) -> Void
      - mutating func remove<S: SequenceType ...>(all: S) -> Void
      - func removed(T) -> Self
      - func removed<S...>(all: S) -> Self
      - Similarly for retain and add
      2. In Scala they primarily use operators, so a Scala like API would
   be:
      - func -=(inout Self, T) -> Void
      - func -=<S: SequenceType ...>(inout Self, S) -> Void
      - func -(T) -> Self
      - func -<S...>(all: S) -> Self
      - Similarly for & and +

Either of these naming patterns seems better than those proposed :(.

  -- Howard.

On 4 April 2016 at 15:49, Thorsten Seitz via swift-evolution < > swift-evolution@swift.org> wrote:

I think Michel and Shawn did raise some good points here.

-Thorsten

Am 03.04.2016 um 22:27 schrieb Shawn Erickson via swift-evolution < >> swift-evolution@swift.org>:

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"

In the "forming" situations it – to me – is ambiguous on if that is in
place or not. To me it implies more of giving something new back.

I am -1 on "form" aspect of this proposal. ...of course things are
learnable as long as things are fairly consistent and not to far out of the
norm for typical language use. Personally I don't see "form" as that
typical in English.

-Shawn

_______________________________________________
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

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

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

···

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”:

http://www.dictionary.com/browse/emplace

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 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”:

http://www.dictionary.com/browse/emplace

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”:
>>
>> http://www.dictionary.com/browse/emplace
>>
>> 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 :frowning:

···

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

Terms of Service

Privacy Policy

Cookie Policy