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