Re: [swift-evolution] API Guidelines: dropFirst?

on Thu Jun 16 2016, David Waite wrote: > I’ve always considered the term of art argument to be at least partially a > red herring. > > These methods are difficult because you don’t have guarantees of > non-mutability until you get to Collection - on Sequence, a dropFirst > method may mean that

Re: [swift-evolution] API Guidelines: dropFirst?

I agree the essence of the "terms of art" can still exist in the base name while applying the "ed/ing rule". I would vote to have these renamed to better align with Swift and less with the terms of art. -Shawn On Thu, Jun 16, 2016 at 10:41 AM Patrick Pijnappel via swift-evolution <

Re: [swift-evolution] API Guidelines: dropFirst?

Hmm, after some consideration I think we should reconsider renaming all of the exceptions (map => mapped, filter => filtered, etc). The main reason to use a term of art is such that people already familiar with the term will immediately understand it. However as Jonathan points out, since the

Re: [swift-evolution] API Guidelines: dropFirst?

I’ve always considered the term of art argument to be at least partially a red herring. These methods are difficult because you don’t have guarantees of non-mutability until you get to Collection - on Sequence, a dropFirst method may mean that neither the original nor returned sequence can

Re: [swift-evolution] API Guidelines: dropFirst?

on Thu Jun 16 2016, Brent Royal-Gordon wrote: >> What is the rationale behind the name dropFirst()? Being a > non-mutating method it should clearly be e.g. droppingFirst() > according to the API Naming Guidelines. > > Like many `Sequence` and `Collection` operations,

Re: [swift-evolution] API Guidelines: dropFirst?

…Thus, I don’t really see the harm in renaming these to match the rest of Swift. It won’t cause any confusion that can’t be easily recovered from. I was outvoted on that though… Thanks, Jon > On Jun 16, 2016, at 5:01 AM, Jonathan Hull wrote: > > I mean that *IF* we were to

Re: [swift-evolution] API Guidelines: dropFirst?

I mean that *IF* we were to rename ‘map’ to ‘mapped’, the compiler would catch this and could recommend the new name. Even if we add a mutating version called ‘map’, it would still catch this case because the mutating version would have a void return. Thanks, Jon > On Jun 16, 2016, at 4:57

Re: [swift-evolution] API Guidelines: dropFirst?

> The signatures are also different, so: > > let newList = list.map(…) > > would throw an error because I have the signature wrong. I'm not sure what you mean by this. What is the error? Why? Does it have something to do with the code you imagine is elided by the ellipses? -- Brent

Re: [swift-evolution] API Guidelines: dropFirst?

> That said I actually think it’s useful to have these methods slightly > different as if I understand them correctly they’re not strictly > non-mutating; a Sequence doesn’t guarantee that it can be consumed over and > over without changing, as it could represent a buffer or some other

Re: [swift-evolution] API Guidelines: dropFirst?

> On 16 Jun 2016, at 08:39, Brent Royal-Gordon via swift-evolution > wrote: > >> What is the rationale behind the name dropFirst()? Being a non-mutating >> method it should clearly be e.g. droppingFirst() according to the API Naming >> Guidelines. > > Like many

Re: [swift-evolution] API Guidelines: dropFirst?

> What is the rationale behind the name dropFirst()? Being a non-mutating > method it should clearly be e.g. droppingFirst() according to the API Naming > Guidelines. Like many `Sequence` and `Collection` operations, `dropFirst()` is a result of the "term of art" exception, which is implied by

[swift-evolution] API Guidelines: dropFirst?

What is the rationale behind the name dropFirst()? Being a non-mutating method it should clearly be e.g. droppingFirst() according to the API Naming Guidelines. I can't seem to find the SE thread dealing with this. ___ swift-evolution mailing list