There were at least two possible solutions:
* Rename @noescape to @nonescaping
* Rename @noescape to @nonescaping, and make @nonescaping the default case
Everyone agrees that we would better resolve issues with @noescape until
Swift 3.
Has anyone prepared a proposal? Has anyone submitted a pull request?
- Anton
Do you mean replace @noescape with its opposite, @escaping?
-DW
On Jun 20, 2016, at 9:39 AM, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:
* Rename @noescape to @nonescaping, and make @nonescaping the default case
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 <david@alkaline-solutions.com>:
On Jun 20, 2016, at 9:39 AM, Антон Жилин via swift-evolution < > swift-evolution@swift.org> wrote:
* Rename @noescape to @nonescaping, and make @nonescaping the default caseDo you mean replace @noescape with its opposite, @escaping?
-DW
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, Антон Жилин <swift-evolution@swift.org> 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 <david@alkaline-solutions.com>:
On Jun 20, 2016, at 9:39 AM, Антон Жилин via swift-evolution < >> swift-evolution@swift.org> wrote:
* Rename @noescape to @nonescaping, and make @nonescaping the default caseDo you mean replace @noescape with its opposite, @escaping?
-DW
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
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 <austinzheng@gmail.com>:
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, Антон Жилин <swift-evolution@swift.org> > 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 <david@alkaline-solutions.com>:
On Jun 20, 2016, at 9:39 AM, Антон Жилин via swift-evolution < >>> swift-evolution@swift.org> wrote:
* Rename @noescape to @nonescaping, and make @nonescaping the default
caseDo you mean replace @noescape with its opposite, @escaping?
-DW
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
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 @escapingFrankly 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.
There is already a thread for this conversation; please respond there.
John.
On Jun 20, 2016, at 10:55 AM, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:
- Anton
2016-06-20 20:37 GMT+03:00 Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>>:
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, Антон Жилин <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <david@alkaline-solutions.com <mailto:david@alkaline-solutions.com>>:
On Jun 20, 2016, at 9:39 AM, Антон Жилин via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
* Rename @noescape to @nonescaping, and make @nonescaping the default caseDo you mean replace @noescape with its opposite, @escaping?
-DW
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution