IIRC, there were at least the following counter-arguments:
1. One must break API and ABI compatibility to add @escaping to an existing
function
2. @nonescaping case is actually quite as common as @escaping
Frankly speaking, I support both of this arguments. I'll also add another
counter-argument.
Lazy map and filter will be marked as @escaping. Now consider the following
code:
func sum<T>(_ array: [T], transform: (T) -> Int) -> Int {
return array.lazy.map(func).reduce(0, combine: +)
}
`transform` will be marked as @escaping, despite that `transform` never
actually escapes `sum`.
I believe that we should not accept nonescaping-by-default until we get a
powerful lifetimes system, as in Rust.
I think it makes sense to create a mini-proposal just for renaming of
@noescape to @nonescaping.
- Anton
2016-06-20 20:37 GMT+03:00 Austin Zheng <[email protected]>:
> Trent Nadeau had prepared a proposal on Chris Lattner's recommendation,
> and there was a discussion thread a few weeks back:
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/19756.
>
> Not sure what the outcome was. I don't see any open PRs to merge the
> proposal into the swift-evolution repo.
>
> Austin
>
> On Mon, Jun 20, 2016 at 9:06 AM, Антон Жилин <[email protected]>
> wrote:
>
>> Hmm, I guess you are right, there would be no point keeping @nonescaping,
>> then.
>>
>> - Anton
>>
>> 2016-06-20 18:55 GMT+03:00 David Waite <[email protected]>:
>>
>>>
>>> On Jun 20, 2016, at 9:39 AM, Антон Жилин via swift-evolution <
>>> [email protected]> wrote:
>>> * Rename @noescape to @nonescaping, and make @nonescaping the default
>>> case
>>>
>>> Do you mean replace @noescape with its opposite, @escaping?
>>>
>>> -DW
>>>
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
