[swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[Kevin Nattinger]

> On Jun 21, 2016, at 10:03 AM, Chris Lattner via swift-evolution <swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution