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

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

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

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

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

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

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

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

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

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 >

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

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

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

> 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

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

> 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

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

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

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

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

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

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 |= &=

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

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

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

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

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

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

Re: [swift-evolution] [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 > : > >> On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution >> wrote: >> > What is your

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

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

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

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 >

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

> 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

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

> 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

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

> 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

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

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