[swift-evolution] [Pitch] Move @noescape

[Chris Lattner]

> On Mar 3, 2016, at 3:01 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> I suppose that makes sense.
> 
> Sorry to double-post, but I'm actually rethinking @autoclosure.
> 
> My feeling is that we should only attach information to the *type* if it follows the value around and if, at least in principle, it would make sense in at least some other type-like contexts. 

I think it does, and let me illustrate why.  Consider an autoclosure-taking function like this (one silly example):

	func f(@autoclosure a : () -> ()) {}

You can use it as you’d expect, e.g.:

	f(print("hello”))

Of course, f is a first class value, and you can assign it:

	let x = f
	x(print("hello"))

This works, because x has type "(@autoclosure () -> ()) -> ()”.  You can see this if you force a type error:

	let y : Int = x
	// error: cannot convert value of type '(@autoclosure () -> ()) -> ()' to specified type 'Int'

However, you can’t write this out explicitly:

	let x2 : (@autoclosure () -> ()) -> () = f
	// error: attribute can only be applied to declarations, not types

This seems dumb to me :-) you should be able to write the type for any declaration you can produce.  Once you do that, it makes sense to spell the original function as:

	func f(a : @autoclosure () -> ()) {}

for consistency.  Yes, I totally get the irony of the fact that @autoclosure used to be on the type in swift 1.

-Chris