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

Sean Heber sean at fifthace.com
Mon Jun 27 15:19:20 CDT 2016


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



More information about the swift-evolution mailing list