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
