When I declare my closure as @noescape, (the default), I explicitly tell
the compiler that, despite the fact closing over it *may* allow it to
escape, I, the programmer, guarantee that it will not.
I would understand a warning, but I don’t understand that the compiler
insists on putting out an error.
So, while the compiler could perhaps, as you say, perform more
sophisticated checks, I don’t even request that. I request however, to
be able to tell the compiler that I know better.
If I am wrong, and if I still let the closure escape despite my promise,
then I made a programming error, and my code can legitimately crash.
I wouldn't like this. I much prefer the current state where this is an
error. That said, it would indeed be great if the compiler were smarter
when it does the analysis whether a closure actually escapes.
There is already a bug report for this, by the way: SR-2274 [1]
[1]: https://bugs.swift.org/browse/SR-2274
This is no different than using the “!” to promise the compiler that an
optional is not nil: if I don’t keep my promise, the program crashes.
Last, in presence of a similar warning (instead of an error), a simple
way to squelch the warning would be to make the @noescape declaration
explicit.
This would require un-deprecating it.
I now feel that I should propose that as an evolution.
What do you think?
Again, I don't think we should go that route. I prefer the status quo.
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
