> On May 18, 2016, at 12:51 PM, Joe Groff <[email protected]> wrote:
>
>>> I thought about this, but { $0 } is already a fairly compact way to express
>>> the identity function.
>>
>> It is, but I worry a bit about the core team's tendency to say "Oh, just use
>> a closure" whenever something like this comes up. A function/method/property
>> name can be merely *read*; a closure must be *interpreted*. And writing
>> closures is error-prone—a slip of the keys and you've written `{ 0 }` or `{
>> 40 }` instead of `{ $0 }`, which look similar and (soon will) work in the
>> same expressions but behave completely differently.
>
> It seems to me that you could just as easily fat-finger `self` when you meant
> `.self`.
If I write `list.map { 0 }` instead of `list.map { $0 }`, that's perfectly
valid code. If I write `list.map(self)` instead of `list.map(.self)`,
> The type system is likely to catch both `{ 0 }` and `self` mistakes.
The type system will immediately (absent some odd overloading) catch `self`
instead of `.self` because you're using an instance where a function is
expected. But `{ 0 }` is a function `T -> Int` where `T -> T` is expected—a
much more subtle difference, particularly since a closure's return value is
often generic and used to determine the return value of the function it's
passed to. So it's pretty likely that `{ 0 }` will satisfy the requirements of
the immediate context; if type-checking is going to fail, it'll be because some
later use of the result expects a `T` instead of an `Int`. So the type-checking
failure will come in a future expression or statement, if indeed it ever does
come at all.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
