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

[Dave Abrahams via swift-evolution]

on Thu Apr 07 2016, Xiaodi Wu  wrote:

> 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 7, 2016 at 7:08 PM Taras Zakharko via swift-evolution
>  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
>  wrote:
> >
> >
> > on Mon Apr 04 2016, Brent Royal-Gordon  
> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via 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 
> 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taras Zakharko via swift-evolution]

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 
>  wrote:
> 
> 
> on Mon Apr 04 2016, Brent Royal-Gordon  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

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

[James Hillhouse via swift-evolution]

Hi Doug,

> What is your evaluation of the proposal?
+1

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes. Swift needs strong Set API’s that play nicey-nicey with the API Guidelines 
and this proposal is a firm effort in that direction.

> Does this proposal fit well with the feel and direction of Swift?
Yes. This proposal takes nouns that have no commonly used verb form and forms 
them into verbs, e.g. ‘union’ into ‘formUnion’. It may not look especially 
pretty to some, but is effective.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
While not languages, the proposal provides SetAlgebra API that is at least as 
understandable as Mathematica and much more so than Matlab. 

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
I’ve been following this discussion since it’s inception back in…what, early 
February? I have read the API’s and diff’s. Many times.

> On Apr 1, 2016, at 12:14 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0059 "Update API Naming Guidelines and Rewrite Set APIs 
> Accordingly" begins now and runs through April 5, 2016. The proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md
>  
> 
> Reply text
> 
> Other replies
>  What 
> goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> Doug Gregor
> 
> Review Manager
> 
> ___
> 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

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

[Dave Abrahams via swift-evolution]

on Mon Apr 04 2016, Sean Heber  wrote:

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

> Example:
>
> var allowedUsers = Set()
> 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 
>>  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

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

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

[Sean Heber via swift-evolution]

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

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

[Brent Royal-Gordon via 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. 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

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

[Douglas Gregor via swift-evolution]

> On Apr 4, 2016, at 9:20 AM, Xiaodi Wu  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
>  wrote:
>> 
>> On Apr 3, 2016, at 1:56 PM, Shawn Erickson  wrote:
>> 
>> 
>> 
>> On Sun, Apr 3, 2016 at 1:27 PM Shawn Erickson  wrote:
>>> 
>>> On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution
>>>  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

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

[Xiaodi Wu via 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
 wrote:
>
> On Apr 3, 2016, at 1:56 PM, Shawn Erickson  wrote:
>
>
>
> On Sun, Apr 3, 2016 at 1:27 PM Shawn Erickson  wrote:
>>
>> On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution
>>  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
>

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

[Douglas Gregor via swift-evolution]

> On Apr 3, 2016, at 1:56 PM, Shawn Erickson  wrote:
> 
> 
> 
> On Sun, Apr 3, 2016 at 1:27 PM Shawn Erickson  > wrote:
> On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution 
> > 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

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

[Dave Abrahams via swift-evolution]

on Fri Apr 01 2016, Brent Royal-Gordon  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.

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.

-- 
Dave

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

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

[Patrick Gili via swift-evolution]

Personally, I don't like any of the options. However, I mentioned this during 
the review of the API naming guidelines. Using the English language to 
construct function names that distinguish between functional and imperative 
forms of the operation places constraints on API designers that produce 
undesirable results. The operations on an algebraic set is merely one example. 
My preference is a symbol appended to the function name (e.g., the exclamation 
point in Ruby). However, it was pointed out at the time that introducing this 
syntax was out-of-scope for Swift 3. What does this mean? We'll revisit this 
later and have to endure the rigor of another API renaming exercise?

Without rehashing the utility of a symbol to distinguish between functional and 
imperative, what is my preference?

Pseudo-verbs? I don't know if this is any better.

A suffix, such as "InPlace", has some appeal for two reasons:

1) It is descriptive and doesn't obfuscate the meaning of the operation.

2) If at sometime later the community sees a practical need to introduce syntax 
to distinguish between functional and imperative forms of an operation, 
removing such a suffix and replacing it with the symbol will mitigate confusion 
of another renaming transition.

Cheers,
-Patrick

> On Apr 2, 2016, at 5:15 PM, Brent Royal-Gordon  wrote:
> 
>> For example, changing union() to formUnion() for the sake of aligning 
>> compliance to API name guidelines simply doesn't make sense to me.
> 
> Given the need for separate names for the functional and imperative forms of 
> this operation, what sorts of names would be better? Pseudo-verbs like 
> `unioning`? An `InPlace` suffix?
> 
> (Everyone else, please don't take this as an invitation to start the 
> bikeshedding again. I'm trying to understand what *this reviewer* prefers.)
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

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

[Xiaodi Wu via 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(all: S) -> Void
>   - func removed(T) -> Self
>   - func removed(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 -=(inout Self, S) -> Void
>   - func -(T) -> Self
>   - func -(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
>>
>>
>> 

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

[Howard Lovatt via swift-evolution]

Looking at other languages:


   1. A Java like API would be:
  - mutating func remove(T) -> Void
  - mutating func remove(all: S) -> Void
  - func removed(T) -> Self
  - func removed(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 -=(inout Self, S) -> Void
  - func -(T) -> Self
  - func -(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

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

[Thorsten Seitz via swift-evolution]

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 
> :
> 
>> On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution 
>>  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

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

[Shawn Erickson via swift-evolution]

On Sun, Apr 3, 2016 at 1:27 PM Shawn Erickson  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.

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

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

[Shawn Erickson via swift-evolution]

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

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

[Michel Fortin via swift-evolution]

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


> Is the problem being addressed significant enough to warrant a change to 
> Swift?

I'm still not entirely convinced any of this is better than the `InPlace` 
suffix we had before. `InPlace` might be ugly visually and grammatically, but 
seems to be the clearest at expressing the intent.


> Does this proposal fit well with the feel and direction of Swift?

There is no question that using a verb instead of the `InPlace` suffix makes 
things fits better with the other API guidelines.


> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?

N/A


> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

Read the guideline and API diffs, thought about a few alternative wording, 
looked in my dictionary.


-- 
Michel Fortin
https://michelf.ca

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

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

[Patrick Gili via swift-evolution]

> What is your evaluation of the proposal?
I am strongly opposed to the changes to the names of functions implementing set 
operations, as it is going to introduce a lot of confusion. While I'm a fairly 
rigid about consistency, I do think that there are acceptable exceptions to any 
set of rules/guidelines. This represents one of those cases. For example, 
changing union() to formUnion() for the sake of aligning compliance to API name 
guidelines simply doesn't make sense to me.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
No.

> Does this proposal fit well with the feel and direction of Swift?
No.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
There are plenty of other languages that have API naming guidelines, such as 
C#, Ruby, and Python. However, they all demonstrate enough lenience to 
accommodate cases such as this. For example, 
http://ruby-doc.org/stdlib-2.3.0/libdoc/set/rdoc/Set.html.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

In-depth.

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

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

[Brent Royal-Gordon via swift-evolution]

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

* * *

My review follows:

> https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md


>   • What is your evaluation of the proposal?

I'm in favor of the updated guidelines and new names; they are straightforward 
and understandable. I'm not entirely happy with `subtract` being different from 
the others, but contorting it to match seems unwise, particularly when we're 
trying to demonstrate the API guidelines.

I have some issues with the new `insert(_:)` return value:

* I'm not sure what the purpose is of returning the new value if a value is 
inserted. Couldn't we return an `Element?` containing the old value if there is 
one, or `nil` if there's a new value?

* If an `insert` might collide with several elements, shouldn't we return a set 
of all the colliding elements, instead of `nil`? (This would do away with the 
exception for `OptionSetType.insert`.)

* Whatever `insert` does, shouldn't `update(with:)` do the same thing? 
Particularly with regards to updating multiple elements?

* How far does this "don't throw away information that's hard to recalculate" 
principle go? Should the mutating operations like `formUnion` return some 
indication of the affected elements? Should the *nonmutating* ones?

* If we're going to officially support equal-but-distinct elements in the 
SetAlgebra API, shouldn't we have an equivalent to NSSet's `member(_:)` method?

We can try to work out these and other issues in this thread, but unless there 
are straightforward answers, I think the better move might be to sever the 
return value change and discuss it separately. It brings up a lot of subtle 
questions across the entire API.

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes. These APIs need to be renamed.

>   • Does this proposal fit well with the feel and direction of Swift?

Yes. It solves an important issue with the guidelines.

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

This API is superior to NSSet/NSMutableSet and Ruby's Set, which are the two 
set APIs I'm most familiar with.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

On the naming issue, I participated heavily in the Threads of Infinite 
Bikeshedding.

On the return value issue, something slightly more than a quick reading.

-- 
Brent Royal-Gordon
Architechies

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

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

[Dave Abrahams via swift-evolution]

Brent Royal-Gordon via swift-evolution  writes:

> A possible mistake in the proposal:

Fixed, thanks!

-Dave

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