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
