[swift-evolution] [Discussion] Terms of Art Swiftification

[Jose Cheyo Jimenez]

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 <swift-evolution at swift.org> 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 <swift-evolution at swift.org> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution