> On Jun 21, 2016, at 10:03 AM, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote: > > Hello Swift community, > > The review of "SE-0102: Remove @noreturn attribute and introduce an empty > NoReturn type" begins now and runs through June 27. The proposal is available > here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md > > Reviews are an important part of the Swift evolution process. All reviews > should be sent to the swift-evolution mailing list at > > https://lists.swift.org/mailman/listinfo/swift-evolution > > or, if you would like to keep your feedback private, directly to the review > manager. > > What goes into a review? > > The goal of the review process is to improve the proposal under review > through constructive criticism and contribute to the direction of Swift. When > writing your review, here are some questions you might want to answer in your > review: > > * What is your evaluation of the proposal?
-1. noreturn is logically and fundamentally an attribute of a function, not a return (pseudo-)type, and it should continue to be expressed that way. If the idea of `@noreturn foo() -> Int` being valid really bothers you so much, just forbid functions declared noreturn from having a specified return type (maybe even an explicit `()`/`Void`). > * Is the problem being addressed significant enough to warrant a change > to Swift? No. There is no problem being solved. noreturn as an attribute is clear, precedented, and easily searchable. Furthermore, I feel the proposal doesn’t even fix most of the “issues” it brings up in the motivation section— `-> NoReturn throws` is no more clear than `@noreturn throws`, and `compose(exit, getExitCode)` is no more clear declared `-> NoReturn` than `@noreturn`. And it introduces ambiguity of its own. If someone defines their own empty enum, does `func foo() -> MyEmptyEnum` get the same treatment as NoReturn? If not, why is it special cased? If so, > * Does this proposal fit well with the feel and direction of Swift? No. We want swift to be intuitive. IMO, `@noreturn` is way more intuitive than saying you’ll return something that you can’t actually follow through with. And everywhere else such a contradiction would be a compiler error. > * If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? It unnecessarily breaks from tradition. The C family uses noreturn attributes. I haven’t seen anyone bring up language where noreturn is achieved in this manner. > * How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? Followed the email chain, thoroughly read the proposal. > > More information about the Swift evolution process is available at > > https://github.com/apple/swift-evolution/blob/master/process.md > > Thank you, > > -Chris Lattner > Review Manager > > _______________________________________________ > swift-evolution mailing list > 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
