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

[Karl]

> On 27 Jun 2016, at 22:19, 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
> 

This is kind of the reverse of how operators work, isn’t it? (Or used to work, I don’t know if they’ve changed since the last time I looked)

We’re definitely having lots of discussions about how the ‘swifty’ way to structure the stdlib would seem a bit alien to people from other languages. C developers wouldn’t discover `(4.4).floor()` or `(4.4).roundedDown()` because their primitive value types don’t have instance methods. At the same time, we seem to have resolved against global functions.

Is better documentation maybe the answer? Perhaps these could be examples in the Swift programming guide. When it comes to functions like `filter`, perhaps a glossary? The standard library is intentionally kept small, so it could be manageable to just keep a mapping of commonly-confused functions.

Ultimately, people are going to a) check code completion, and failing that b) google it. For things like ‘filter’, it’s a one-off friction of a handful of seconds. Maybe we should just be more ruthless; maybe we can afford to be these days.

Karl