Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Mon Jun 27 2016, Patrick Smith wrote: > Side question: is there going to be any situation where I’m iterating > through a sequence/collection that I wouldn’t want to always use > `lazy`? Is `lazy` *always* going to be more efficient than the > array-creating defaults when the result is iterat

Re: [swift-evolution] Stdlib closure argument labels and parameter names

Side question: is there going to be any situation where I’m iterating through a sequence/collection that I wouldn’t want to always use `lazy`? Is `lazy` *always* going to be more efficient than the array-creating defaults when the result is iterated? For instance, something much better than thi

Re: [swift-evolution] Stdlib closure argument labels and parameter names

> After all, it's absurd that a closure would be supplied as an argument for > any purpose other than being done or invoked or performed. In the calls at hand, like `withUnsafeMutablePointer`, "do" is the verb of the call. That is not true of many—perhaps most—closures. For instance, the verb of

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Fri Jun 24 2016, Anton Zhilin wrote: >> +100. I even want to brought the term-of-art argument here. IMO These >> functions are expected to be called without any parameter names. > > That would probably be a good scenario, but core team needs to release > their grip on strictly following new

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Mon Jun 27 2016, Erica Sadun wrote: >> On Jun 27, 2016, at 1:05 PM, Dave Abrahams wrote: >> >> >> on Mon Jun 27 2016, Erica Sadun > > wrote: >> > On Jun 27, 2016, at 12:02 PM, Dave Abrahams wrote: on Mon Jun 27 2016, Erica Sadun wro

Re: [swift-evolution] Stdlib closure argument labels and parameter names

> On Jun 27, 2016, at 1:05 PM, Dave Abrahams wrote: > > > on Mon Jun 27 2016, Erica Sadun > wrote: > >>> On Jun 27, 2016, at 12:02 PM, Dave Abrahams wrote: >>> >>> >>> on Mon Jun 27 2016, Erica Sadun wrote: >>> >> > On Jun 27, 2016, at 8:40 AM, Dave

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Mon Jun 27 2016, Erica Sadun wrote: >> On Jun 27, 2016, at 12:02 PM, Dave Abrahams wrote: >> >> >> on Mon Jun 27 2016, Erica Sadun wrote: >> > On Jun 27, 2016, at 8:40 AM, Dave Abrahams via swift-evolution wrote: “each” is just what's required to make “so” read sensibly.

Re: [swift-evolution] Stdlib closure argument labels and parameter names

> On Jun 27, 2016, at 12:02 PM, Dave Abrahams wrote: > > > on Mon Jun 27 2016, Erica Sadun wrote: > >>> On Jun 27, 2016, at 8:40 AM, Dave Abrahams via swift-evolution >>> wrote: >>> “each” is just what's required to make “so” read sensibly. >>> >>> (0..<100).filter(so: isPrime) >>> >>>

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Mon Jun 27 2016, Erica Sadun wrote: >> On Jun 27, 2016, at 8:40 AM, Dave Abrahams via swift-evolution >> wrote: >> “each” is just what's required to make “so” read sensibly. >> >>(0..<100).filter(so: isPrime) >> >> doesn't make any obvious sense. > > Shouldn't there be a term of art e

Re: [swift-evolution] Stdlib closure argument labels and parameter names

On 27.06.2016 19:02, Erica Sadun via swift-evolution wrote: On Jun 27, 2016, at 8:40 AM, Dave Abrahams via swift-evolution mailto:swift-evolution@swift.org>> wrote: “each” is just what's required to make “so” read sensibly. (0..<100).filter(so: isPrime) doesn't make any obvious sense. S

Re: [swift-evolution] Stdlib closure argument labels and parameter names

Just tossing my vote in the hat for renaming .filter() to something like .select() since that better matches what it does, IMO. “Filter” is almost like the opposite word from what it should be since the closure returning true is what decides what is included in the results, not what is filtered

Re: [swift-evolution] Stdlib closure argument labels and parameter names

> On Jun 27, 2016, at 8:40 AM, Dave Abrahams via swift-evolution > wrote: > “each” is just what's required to make “so” read sensibly. > >(0..<100).filter(so: isPrime) > > doesn't make any obvious sense. Shouldn't there be a term of art exemption for `filter(_:)`. Otherwise why not use

Re: [swift-evolution] Stdlib closure argument labels and parameter names

> On Jun 27, 2016, at 7:05 AM, Dave Abrahams wrote: >> for i in map { ... } { // will not compile >>... >> } > > I don't think Swift wants to buy into the idea that using map without > trailing closures is a bad habit. We strongly believe in trailing > closure syntax. I strongly believe t

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Mon Jun 27 2016, Xiaodi Wu wrote: > On Mon, Jun 27, 2016 at 9:10 AM, Dave Abrahams > wrote: > >> >> on Sun Jun 26 2016, Xiaodi Wu wrote: >> >> > On Sun, Jun 26, 2016 at 2:18 PM, Erica Sadun via swift-evolution < >> > swift-evolution@swift.org> wrote: >> > >> >> >> >> See below. But in a nu

Re: [swift-evolution] Stdlib closure argument labels and parameter names

On Mon, Jun 27, 2016 at 9:10 AM, Dave Abrahams wrote: > > on Sun Jun 26 2016, Xiaodi Wu wrote: > > > On Sun, Jun 26, 2016 at 2:18 PM, Erica Sadun via swift-evolution < > > swift-evolution@swift.org> wrote: > > > >> > >> See below. But in a nutshell, `do` gets the idea across. It's short. > >> I

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Sun Jun 26 2016, Xiaodi Wu wrote: > On Sun, Jun 26, 2016 at 2:18 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> See below. But in a nutshell, `do` gets the idea across. It's short. >> It's pithy. It uses a common, comfortable word. So yes, personal >> tast

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Sun Jun 26 2016, Erica Sadun wrote: >> On Jun 26, 2016, at 10:35 AM, Dave Abrahams wrote: >> >> >> on Sat Jun 25 2016, Erica Sadun > > wrote: > >> >>> On Jun 25, 2016, at 4:25 PM, Dave Abrahams wrote: on Wed Jun 22 2016, Erica Sadun wrote: On J

Re: [swift-evolution] Stdlib closure argument labels and parameter names

> On 24 Jun 2016, at 16:26, Charlie Monroe via swift-evolution > wrote: > >> >> On Jun 24, 2016, at 4:11 PM, Anton Zhilin via swift-evolution >> wrote: >> >> Vladimir.S via swift-evolution writes: >> >>> Do you mean *sorted*(by:) ? Or I'm missing something in naming rules? >> >> IIRC, so

Re: [swift-evolution] Stdlib closure argument labels and parameter names

On Sun, Jun 26, 2016 at 2:18 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > > On Jun 26, 2016, at 10:35 AM, Dave Abrahams wrote: > > > on Sat Jun 25 2016, Erica Sadun > wrote: > > On Jun 25, 2016, at 4:25 PM, Dave Abrahams wrote: > > o

Re: [swift-evolution] Stdlib closure argument labels and parameter names

> I like `predicate`. I endorse `predicate`. Does this mean the rule of "must > read like a sentence" can be overturned for things like "comparison" and > "order"? If so, woo! I've suggested that a few emails back as well, but I've asked myself if it's not a bit confusing when you have (NS)Predic

Re: [swift-evolution] Stdlib closure argument labels and parameter names

> On Jun 26, 2016, at 10:35 AM, Dave Abrahams wrote: > > > on Sat Jun 25 2016, Erica Sadun > wrote: > >> On Jun 25, 2016, at 4:25 PM, Dave Abrahams wrote: >>> on Wed Jun 22 2016, Erica Sadun wrote: >>> On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evo

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Sat Jun 25 2016, Erica Sadun wrote: > On Jun 25, 2016, at 4:25 PM, Dave Abrahams wrote: >> on Wed Jun 22 2016, Erica Sadun wrote: >> On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution >> wrote: >>> >>> -func forEach(_ body: (S.Iterator.Element) -> ()) >>> +func forEac

Re: [swift-evolution] Stdlib closure argument labels and parameter names

> On 26 Jun 2016, at 02:03, Erica Sadun via swift-evolution > wrote: > > On Jun 25, 2016, at 4:25 PM, Dave Abrahams > wrote: >> on Wed Jun 22 2016, Erica Sadun > > wrote: >> On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolut

Re: [swift-evolution] Stdlib closure argument labels and parameter names

On Jun 25, 2016, at 4:25 PM, Dave Abrahams wrote: > on Wed Jun 22 2016, Erica Sadun wrote: > On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution > wrote: >> >> -func forEach(_ body: (S.Iterator.Element) -> ()) >> +func forEach(invoke body: (S.Iterator.Element) -> ()) >> >>

Re: [swift-evolution] Stdlib closure argument labels and parameter names

Comments inline: Sent from my iPhone > On 26 Jun 2016, at 00:25, Dave Abrahams via swift-evolution > wrote: > > >> on Wed Jun 22 2016, Erica Sadun wrote: >> >>> On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> Hi All, >>> >>> A couple of weeks ago

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Thu Jun 23 2016, Erica Sadun wrote: >> On Jun 23, 2016, at 12:39 AM, David Hart wrote: >>> - for test in removeFirstTests.filter({ $0.numberToRemove == 1 }) { >>> + for test in removeFirstTests.filter( >>> +suchThat: { $0.numberToRemove == 1 } >>> >>> The difference betwee

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Wed Jun 22 2016, David Hart wrote: > I did not pay a lot of attention to this renaming because I thought > the trailing closure syntax would shield me from labels. But I forgot > that in if/for/while statements, I’m going to be forced to use > them. In those cases, I’d prefer more succinct la

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Wed Jun 22 2016, Erica Sadun wrote: > On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution > wrote: >> >> >> Hi All, >> >> A couple of weeks ago we started to notice that we had some poorly-named >> closure parameters and argument labels in the standard library, so we >> did a

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Wed Jun 22 2016, Xiaodi Wu wrote: > On Wed, Jun 22, 2016 at 8:12 PM, Sean Heber wrote: > >> How about: >> >> let results = possibilities.where(matching: closure) >> > > My understanding is that we're restricting the bikeshedding here to the > closure label. Renaming `filter` is discussed in

Re: [swift-evolution] Stdlib closure argument labels and parameter names

Yes, I think the long names somewhat reduces the argument for keeping ‘terms of art’, as in this proposal the method names are describing themselves twice. Is the extra clarity for those who are not familiar with `filter`, `map`, `reduce` etc from other languages? Is this extra clarity actually

Re: [swift-evolution] Stdlib closure argument labels and parameter names

> On Jun 24, 2016, at 4:11 PM, Anton Zhilin via swift-evolution > wrote: > > Vladimir.S via swift-evolution writes: > >> Do you mean *sorted*(by:) ? Or I'm missing something in naming rules? > > IIRC, sort is mutating and sorted is nonmutating (copying) version. > Also, I forgot `initial` pa

Re: [swift-evolution] Stdlib closure argument labels and parameter names

Vladimir.S via swift-evolution writes: > Do you mean *sorted*(by:) ? Or I'm missing something in naming rules? IIRC, sort is mutating and sorted is nonmutating (copying) version. Also, I forgot `initial` parameter in `reduce`. > > Data flow is an area where code becomes the less understandable

Re: [swift-evolution] Stdlib closure argument labels and parameter names

On 24.06.2016 0:55, Anton Zhilin via swift-evolution wrote: Dave Abrahams via swift-evolution writes: A couple of weeks ago we started to notice that we had some poorly- named closure parameters and argument labels in the standard library, so we did a complete audit of the standard library's

Re: [swift-evolution] Stdlib closure argument labels and parameter names

> On Jun 23, 2016, at 12:39 AM, David Hart wrote: >> - for test in removeFirstTests.filter({ $0.numberToRemove == 1 }) { >> + for test in removeFirstTests.filter( >> +suchThat: { $0.numberToRemove == 1 } >> >> The difference between `filter` and `forEach` is that `forEach` is

Re: [swift-evolution] Stdlib closure argument labels and parameter names

Dave Abrahams via swift-evolution writes: > A couple of weeks ago we started to notice that we had some poorly- named > closure parameters and argument labels in the standard library, so we > did a complete audit of the standard library's APIs and came up with a > preliminary proposal for changes

Re: [swift-evolution] Stdlib closure argument labels and parameter names

I did not pay a lot of attention to this renaming because I thought the trailing closure syntax would shield me from labels. But I forgot that in if/for/while statements, I’m going to be forced to use them. In those cases, I’d prefer more succinct labels. I added some comments inline where I ha

Re: [swift-evolution] Stdlib closure argument labels and parameter names

Let's not go through more churn with `pointee`. It's already just been changed from `memory`. On Wed, Jun 22, 2016 at 21:02 Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >

Re: [swift-evolution] Stdlib closure argument labels and parameter names

On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution wrote: > > > Hi All, > > A couple of weeks ago we started to notice that we had some poorly-named > closure parameters and argument labels in the standard library, so we > did a complete audit of the standard library's APIs and cam

Re: [swift-evolution] Stdlib closure argument labels and parameter names

On Wed, Jun 22, 2016 at 8:12 PM, Sean Heber wrote: > How about: > > let results = possibilities.where(matching: closure) > My understanding is that we're restricting the bikeshedding here to the closure label. Renaming `filter` is discussed in another thread, though obviously that would change t

Re: [swift-evolution] Stdlib closure argument labels and parameter names

How about: let results = possibilities.where(matching: closure) :) l8r Sean Sent from my iPad > On Jun 22, 2016, at 8:00 PM, Xiaodi Wu via swift-evolution > wrote: > > filter(extractingWhere:) >> On Wed, Jun 22, 2016 at 18:53 Dave Abrahams via swift-evolution >> wrote: >> >> on Wed Jun

Re: [swift-evolution] Stdlib closure argument labels and parameter names

filter(extractingWhere:) On Wed, Jun 22, 2016 at 18:53 Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Wed Jun 22 2016, Xiaodi Wu wrote: > > > I'll duly oblige with some pushback on `suchThat`. I get that you're > trying > > to clarify whether filter retains or gets r

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Wed Jun 22 2016, Xiaodi Wu wrote: > I'll duly oblige with some pushback on `suchThat`. I get that you're trying > to clarify whether filter retains or gets rid of elements that match the > predicate, but I don't think "filter such that" expresses this idea at all. > > Comparing to "filter whe

Re: [swift-evolution] Stdlib closure argument labels and parameter names

I'll duly oblige with some pushback on `suchThat`. I get that you're trying to clarify whether filter retains or gets rid of elements that match the predicate, but I don't think "filter such that" expresses this idea at all. Comparing to "filter where," "filter such that" is equally susceptible to

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Tue Jun 21 2016, Dave Abrahams wrote: > on Mon Jun 20 2016, Brent Royal-Gordon wrote: > >>> A couple of weeks ago we started to notice that we had some poorly-named >>> closure parameters and argument labels in the standard library, so we >>> did a complete audit of the standard library's AP

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Mon Jun 20 2016, Brent Royal-Gordon wrote: >> A couple of weeks ago we started to notice that we had some poorly-named >> closure parameters and argument labels in the standard library, so we >> did a complete audit of the standard library's APIs and came up with a >> preliminary proposal for

Re: [swift-evolution] Stdlib closure argument labels and parameter names

> On 21 Jun 2016, at 01:52, Brent Royal-Gordon via swift-evolution > wrote: > > * I'm very uncomfortable with the amount of weight `accumulatingResultBy` > adds to `reduce`. `combinedBy` seems perfectly cromulent to me. I'm even more > concerned by your suggestion in the pull request body of

Re: [swift-evolution] Stdlib closure argument labels and parameter names

> A couple of weeks ago we started to notice that we had some poorly-named > closure parameters and argument labels in the standard library, so we > did a complete audit of the standard library's APIs and came up with a > preliminary proposal for changes, which we applied in a branch and you > can

[swift-evolution] Stdlib closure argument labels and parameter names

Hi All, A couple of weeks ago we started to notice that we had some poorly-named closure parameters and argument labels in the standard library, so we did a complete audit of the standard library's APIs and came up with a preliminary proposal for changes, which we applied in a branch and you can