Re: [swift-evolution] [SR-933] Rename flatten to flattened

> On Apr 21, 2016, at 1:08 AM, Vladimir.S via swift-evolution > wrote: >> > > Is it "SE-0006" ? > https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md > >

Re: [swift-evolution] [SR-933] Rename flatten to flattened

On 20.04.2016 20:47, Dave Abrahams wrote: on Tue Apr 19 2016, "Vladimir.S" wrote: Dave, could you clarify your message with more details please. Are you saying that "map" will be "map" in Swift 3.0 That is the current plan of record. Oh, thank you for clarifying this. and that "flatte

Re: [swift-evolution] [SR-933] Rename flatten to flattened

on Tue Apr 19 2016, "Vladimir.S" wrote: > Dave, could you clarify your message with more details please. > Are you saying that "map" will be "map" in Swift 3.0 That is the current plan of record. > and that "flatten" is the same kind of special case when we don't need > to rename it? Yes, “f

Re: [swift-evolution] [SR-933] Rename flatten to flattened

Dave, could you clarify your message with more details please. Are you saying that "map" will be "map" in Swift 3.0 and that "flatten" is the same kind of special case when we don't need to rename it? Just checked. Don't understand. In Swift 3.0 (mar 24) there are "map" "filter" "reduce", not

Re: [swift-evolution] [SR-933] Rename flatten to flattened

on Tue Apr 19 2016, "Vladimir.S via swift-evolution" wrote: > Although I personally don't feel this is right decision(renaming) for > a number of reasons, but the new API Design Guidelines were already > accepted and it seems like nothing can be changed already: > > API Design Guidelines (SE-00

Re: [swift-evolution] [SR-933] Rename flatten to flattened

> On 19 Apr 2016, at 17:19, Brent Royal-Gordon wrote: > >>> I wrote my first Python this week. I was very glad that `map` was named >>> `map`. I just had to glance at the docs to see whether it was a function or >>> a method and which argument came first. It took less time and involved less >

Re: [swift-evolution] [SR-933] Rename flatten to flattened

Although I personally don't feel this is right decision(renaming) for a number of reasons, but the new API Design Guidelines were already accepted and it seems like nothing can be changed already: API Design Guidelines (SE-0023) https://github.com/apple/swift-evolution/blob/master/proposals/002

Re: [swift-evolution] [SR-933] Rename flatten to flattened

>> I wrote my first Python this week. I was very glad that `map` was named >> `map`. I just had to glance at the docs to see whether it was a function or >> a method and which argument came first. It took less time and involved less >> doubt than learning their closure syntax did. > > Are you s

Re: [swift-evolution] [SR-933] Rename flatten to flattened

On keeping map() as map() but keeping the -ed and -ing guideline for other APIs: What defines prior art really? I’m fairly new to functional programming, but I imagine there is a plethora of other API designs that can be copied. In Swift, do they all take on the past-particle naming?  Which consi

Re: [swift-evolution] [SR-933] Rename flatten to flattened

> On 19 Apr 2016, at 10:40, Brent Royal-Gordon via swift-evolution > wrote: > >> Totally agree with Brent, too. And I wouldn't rename flatten either. > > A brief postscript on terms of art: > > I wrote my first Python this week. I was very glad that `map` was named > `map`. I just had to gla

Re: [swift-evolution] [SR-933] Rename flatten to flattened

> Totally agree with Brent, too. And I wouldn't rename flatten either. A brief postscript on terms of art: I wrote my first Python this week. I was very glad that `map` was named `map`. I just had to glance at the docs to see whether it was a function or a method and which argument came first.

Re: [swift-evolution] [SR-933] Rename flatten to flattened

Totally agree with Brent, too. And I wouldn't rename flatten either. -Thorsten > Am 11.04.2016 um 08:03 schrieb David Hart via swift-evolution > : > > Totally agree with Brent, map/flatMap are terms of art. > > Sent from my iPad > > On 10 Apr 2016, at 23:11, Brent Royal-Gordon via swift-evol

Re: [swift-evolution] [SR-933] Rename flatten to flattened

on Sat Apr 16 2016, Patrick Smith wrote: > Yes, I agree. I think in the guidelines should be a recommendation for > mutating methods are preferred, when nonmutating are preferred, and > when to have both. It would be interesting to see such a guideline. OK, off the cuff: Having a nonmutating

Re: [swift-evolution] [SR-933] Rename flatten to flattened

+1, almost totally agree. IMO sort/map/filter/reduce/etc "belongs" to the functional word, as I can see Swift is moving to be more functional language, we like to use functional features like some.filter{}.map{}.reduce{}, we like such frameworks/libs like RxSwift/ReacriveCocoa, we are implemen

Re: [swift-evolution] [SR-933] Rename flatten to flattened

Yes, I agree. I think in the guidelines should be a recommendation for mutating methods are preferred, when nonmutating are preferred, and when to have both. If performance is a key goal of Swift, so much that it influences API design, then some details should be part of the guidelines also. Pat

Re: [swift-evolution] [SR-933] Rename flatten to flattened

By “the big three”, are you referring to only the naming of map, filter, and reduce? I would also like to see a formal proposal along these lines, and possibly more. I also feel that the `inPlace` suffix was very clear (most important) and very much liked that it made the immutable version t

Re: [swift-evolution] [SR-933] Rename flatten to flattened

After hitting Send button, I remembered that "Enhanced floating-point protocols" proposal uses `add`, `subtract`, `multiply` and `divide` names for mutating versions. They should be non-mutating by default, as well as other purely mathematical terms. I don't know how it can be unobvious. - Anton

Re: [swift-evolution] [SR-933] Rename flatten to flattened

Thinking about it, `ed`/`ing` and even `form` prefix might not be that bad. It's more a matter of what should be "default" in a specific domain. In imperative domain, mutating version usually feels as the most natural one. Think `sort`. Everyone knows that sort must modify the array (usually throu

Re: [swift-evolution] [SR-933] Rename flatten to flattened

> On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution > wrote: > > I've already expressed these concerns, but nobody noticed, apparently. Here > is it: > > I think current -ed/-ing convention is ugly. It breaks syntactic correctness, > experience from other languages, mathematical

[swift-evolution] [SR-933] Rename flatten to flattened

I've already expressed these concerns, but nobody noticed, apparently. Here is it: I think current -ed/-ing convention is ugly. It breaks syntactic correctness, experience from other languages, mathematical notation and functional idioms. `InPlace` suffix was so far more correct in these terms. W

Re: [swift-evolution] [SR-933] Rename flatten to flattened

I agree with this and add that the 2.2 naming is unambiguous. There’s no doubt what is meant by sortInPlace(). > On Apr 14, 2016, at 9:26 AM, David Rönnqvist via swift-evolution > wrote: > > I don’t particularly like these name changes. > > I would even go as far as saying that these recent

Re: [swift-evolution] [SR-933] Rename flatten to flattened

I don’t particularly like these name changes. I would even go as far as saying that these recent discussions about renaming flatten, map, filter, reduce has made me question the original Swift 3 API renaming. What I mostly like about the current (2.2) naming is that the non-mutating version is

Re: [swift-evolution] [SR-933] Rename flatten to flattened

With regard to trig they are functions: let s = sin(x) so not really relevant. But if the were made members then: let s = x.sined x.sin() Would read well. On Tuesday, 12 April 2016, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > >> Do you also think that tri

Re: [swift-evolution] [SR-933] Rename flatten to flattened

>> Do you also think that trigonometry should be `foo.sined`, `foo.cosined`, >> and `foo.tangented`? > > sine, cosine etc. are all nouns so I think as computed properties they’d be > fine as is? So you would favor these? _ = number.sine() _ = number.cosine() _ = number.

Re: [swift-evolution] [SR-933] Rename flatten to flattened

on Sun Apr 10 2016, Arsen Gasparyan wrote: > Ok. Is it final decision? No, any API change needs to go through review on the evolution list. Also, FWIW, I am not particularly keen on changing these names. > Can I start working on it? > > On Sun, 10 Apr 2016 at 23:07, Howard Lovatt via swift-ev

Re: [swift-evolution] [SR-933] Rename flatten to flattened

I think current -ed/-ing convention is very ugly. It breaks syntactic correctness, experience from other languages, mathematical notation and functional idioms. `InPlace` suffix was so far more correct in these terms. We can make anything a convention, but should we? I liked the proposal about

Re: [swift-evolution] [SR-933] Rename flatten to flattened

> On 10 Apr 2016, at 22:11, Brent Royal-Gordon wrote: > > Do you also think that trigonometry should be `foo.sined`, `foo.cosined`, and > `foo.tangented`? sine, cosine etc. are all nouns so I think as computed properties they’d be fine as is? > If there is a universally-accepted nomenclature

Re: [swift-evolution] [SR-933] Rename flatten to flattened

Totally agree with Brent, map/flatMap are terms of art. Sent from my iPad On 10 Apr 2016, at 23:11, Brent Royal-Gordon via swift-evolution wrote: >> I still don’t see what’s being lost here, it’s not like the proposal is to >> radically rename them, all we’d end up with is .mapped(), .flatten

Re: [swift-evolution] [SR-933] Rename flatten to flattened

> I still don’t see what’s being lost here, it’s not like the proposal is to > radically rename them, all we’d end up with is .mapped(), .flattened(), > .filtered() etc., which any good search engine should still be able to find, > and will still come up in auto-completion if you start typing .m

Re: [swift-evolution] [SR-933] Rename flatten to flattened

Ok. Is it final decision? Can I start working on it? On Sun, 10 Apr 2016 at 23:07, Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote: > Do it to them all: flatMapped, unioned, etc. > > On Monday, 11 April 2016, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wro

Re: [swift-evolution] [SR-933] Rename flatten to flattened

Do it to them all: flatMapped, unioned, etc. On Monday, 11 April 2016, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri Apr 08 2016, Brent Royal-Gordon > wrote: > > >> The 'flatten()' method didn't get the Swift 3 API renaming treatment > >> it should have, to go

Re: [swift-evolution] [SR-933] Rename flatten to flattened

on Fri Apr 08 2016, Brent Royal-Gordon wrote: >> The 'flatten()' method didn't get the Swift 3 API renaming treatment >> it should have, to go along with reversed, sorted, joined, etc. >> As I see Dmitri Gribenko already agree with it but we still have to >> discuss it here. So what do you think

Re: [swift-evolution] [SR-933] Rename flatten to flattened

Yet another +1 for Haravikk's suggestion. Naming conventions are a good thing and mapped, filtered etc. are a perfect fit. I don't see a reason for an exception here. R+ Sent from my iPhone > On 09 Apr 2016, at 11:03, Haravikk via swift-evolution > wrote: > > >> On 9 Apr 2016, at 01:32, Br

Re: [swift-evolution] [SR-933] Rename flatten to flattened

+1 for Haravikk's reasoning, mapped etc. are the best choice. On Saturday, 9 April 2016, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > > > On 9 Apr 2016, at 01:32, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org > wrote: > > > > `flatten` is nowhere near

Re: [swift-evolution] [SR-933] Rename flatten to flattened

> On 9 Apr 2016, at 01:32, Brent Royal-Gordon via swift-evolution > wrote: > > `flatten` is nowhere near as weak a term of art as `takeWhile`, but I think > it still falls towards that end of the spectrum. We shouldn't worry too much > about changing it. `map`, `reduce`, and `filter` are much

Re: [swift-evolution] [SR-933] Rename flatten to flattened

Thanks Brent -- I completely agree with your assessment. I was failing to come up with the proper argument for just about the same idea! Guillaume Lessard > On 8 avr. 2016, at 18:32, Brent Royal-Gordon via swift-evolution > wrote: > >> The 'flatten()' method didn't get the Swift 3 API renamin

Re: [swift-evolution] [SR-933] Rename flatten to flattened

> The 'flatten()' method didn't get the Swift 3 API renaming treatment it > should have, to go along with reversed, sorted, joined, etc. > As I see Dmitri Gribenko already agree with it but we still have to discuss > it here. So what do you think? I'm in favor. Though all of these things are te

Re: [swift-evolution] [SR-933] Rename flatten to flattened

> On Apr 8, 2016, at 4:19 AM, Haravikk via swift-evolution > wrote: > If we want mutating forms of this methods then I much prefer .map() and > .mapped() to .map() and .mapInPlace() or whatever, as the latter contradicts > the naming convention used everywhere else which only adds confusion

Re: [swift-evolution] [SR-933] Rename flatten to flattened

on Fri Apr 08 2016, Pyry Jahkola wrote: > On 08 Apr 2016, at 13:19, Haravikk via swift-evolution > wrote: > > I think it makes sense to just rename them; it’s not as though flattened > or > mapped is somehow far removed from the original meaning as the actual > action > is

Re: [swift-evolution] [SR-933] Rename flatten to flattened

> On 8 Apr 2016, at 12:00, Pyry Jahkola wrote: > > >> On 08 Apr 2016, at 13:19, Haravikk via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I think it makes sense to just rename them; it’s not as though flattened or >> mapped is somehow far removed from the original meani

Re: [swift-evolution] [SR-933] Rename flatten to flattened

> On 08 Apr 2016, at 13:19, Haravikk via swift-evolution > wrote: > > I think it makes sense to just rename them; it’s not as though flattened or > mapped is somehow far removed from the original meaning as the actual action > is the same, it’s just changing tense. -1, and not only for the r

Re: [swift-evolution] [SR-933] Rename flatten to flattened

> On 7 Apr 2016, at 19:12, Dave Abrahams via swift-evolution > wrote: > > We kept flatten as is because it is part of a suite of methods that are terms > of art from functional programming (map, filter, flatMap, reduce) that don't > follow the naming guidelines I think it makes sense to just

Re: [swift-evolution] [SR-933] Rename flatten to flattened

I would prefer to change them all: mapped, filtered, flatMapped, reduced, and flattened. On Friday, 8 April 2016, David Waite via swift-evolution < swift-evolution@swift.org> wrote: > In the sense that these are existing terms of art from functional > programming, they inherit the meaning of bein

Re: [swift-evolution] [SR-933] Rename flatten to flattened

In the sense that these are existing terms of art from functional programming, they inherit the meaning of being non-mutating. If we did consider changing the name of one, I’d prefer if we considered all of them at once (so the various bike sheds would be painted in complementary colors) -DW

Re: [swift-evolution] [SR-933] Rename flatten to flattened

on Thu Apr 07 2016, Arsen Gasparyan wrote: > Hey guys, > > The 'flatten()' method didn't get the Swift 3 API renaming treatment it should > have, to go along with reversed, sorted, joined, etc. > As I see Dmitri Gribenko already agree with it but we still have to discuss it > here. So what do yo

Re: [swift-evolution] [SR-933] Rename flatten to flattened

I agree. The related types (currently FlattenCollection, FlattenSequence) should get renamed as well. Cheers, Guillaume Lessard ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [SR-933] Rename flatten to flattened

Hey guys, The 'flatten()' method didn't get the Swift 3 API renaming treatment it should have, to go along with reversed, sorted, joined, etc. As I see Dmitri Gribenko already agree with it but we still have to discuss it here. So what do you think? Implementation: https://github.com/apple/swift/