I would support a rename of filter to the right name. This is a little silly but wouldn't select(…) become selecting(…) with the naming rules? I think where(…) would only make sense if it was lazy by default. There probably needs to be a whole survey of names (seems kinda late for swift 3). I would be afraid of a function type alias fractioning the language. Naming is hard.
> On Jun 27, 2016, at 1:19 PM, Sean Heber via swift-evolution > <[email protected]> wrote: > > Here’s a perhaps unlikely “what if” idea that is tangentially related to the > problem that FP and mathematical names are sometimes weird in Swift and often > don’t have a place to “live” that makes sense. > > Let’s say we add an ability to declare a function on a > struct/protocol/class/enum as a “functionalAlias” (for lack of a better name) > which creates both a normal method, but also an effectively global function > of the same (or an alternate given) name for use in functional scenarios. > > Example: > > struct Float { > @functionalAlias(floor) func roundedDown() -> Float { return … } > } > > This would allow you to do this: > > let value: Float = 42 > let a = value.roundedDown() > let b = floor(value) > > Essentially, the compiler generates something sort of like this for you: > > extension Float { > static func floor(_ v: Float) -> Float { return v.roundedDown() } > } > > When looking up a global function, the compiler would include these generated > static functions as if they were top-level functions and proceed pretty much > like normal. If there is any ambiguity, since the auto-generated function are > effectively declared as a static inside of another type, you could always > disambiguate with “Float.floor” if necessary. > > Obviously this is just brainstorming/talking out loud. Maybe this is silly. > Maybe it’s terrible. (Probably both.) > > l8r > Sean > > > >> On Jun 27, 2016, at 2:31 PM, Erica Sadun via swift-evolution >> <[email protected]> wrote: >> >> Under consideration is the resolution that "some terms of art while >> appropriate to many FP languages, may be better served by using Swift names." >> >> Consider, for example, `filter(_:)`. Sean Heber writes, >> >>> 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 >>> *from* the results. I mean, yeah, I can kind of understand the logic either >>> way, but it’s always been one of those strange mental gymnastics things." >> >> When asked "Shouldn't there be a term of art exemption for `filter(_:)`. >> Otherwise why not use `select(where:)`," Dave Abrahams replies: >> >>> Because `where(...)` is better. >> >> Have at it. >> >> -- E >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
