[swift-evolution] [Review] SE-0090: Remove .self and freely allow type references in expressions

[Brent Royal-Gordon]

> On May 18, 2016, at 12:51 PM, Joe Groff <jgroff at apple.com> 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