So I suppose you feel this case is different from the (unsafe) implicitly unwrapping of optionals with the “!” operator.
Why do you feel the situation is different? > On 10 Oct 2016, at 17:34, Ole Begemann <o...@oleb.net> wrote: > >> 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
