[swift-evolution] Utilizing arguments without meaningful internal names

[Brent Royal-Gordon]

> e.g. Here’s an operator I use (I saw something very similar recently called “then”).
> 
> public func …<Type>(
>    _$0: Type,
>    @noescape ƒ0: Type -> ()
> ) -> Type {
>    ƒ0(_$0)
>    return _$0
> }
> 
> In the future, I’d prefer to keep the documentation the same, but have the code be this:
> 
> public let …<Type>(Type, @noescape Type -> ()) {
>    ƒ0(.0)
>    return .0
> }

Both of these examples seem strictly less readable than this:

	public func … <Value>(value: Value, accessor: @noescape Value -> ()) -> Value {
		accessor(value)
		return value
	}

They're shorter, but brevity is not a virtue if it makes your code less clear. Swift is not APL.

> 1. The distinction between immutable closures and functions should dissolve, hence “let" 

How do you handle overloading? `let` shadows, while `func` overloads.

Also, what is actually gained by eliminating the keyword marking functions as different from constants?

> 2. Trailing closures should be known by default as ƒ0, ƒ1, etc.

So, how many people know how to type ƒ? I sure don't.

> 3. $ is ugly and should be changed to .

Which already has a different meaning, looking up a static property or method on the contextually expected type.

> 4. Return type should be implicit

Eliminating the one rock—function signatures—that Swift's type inference system, which already can easily get into serious computational complexity, has to cling to.

-- 
Brent Royal-Gordon
Architechies