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

[Michael Peternell]

> Am 21.06.2016 um 19:03 schrieb Chris Lattner via swift-evolution <swift-evolution at swift.org>:
> 
> 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
I like the common assumption that when a function returns a type T, it means that the function returns a value of type T. A function that does *not* return, does not return a value of type T, for any T. Specifically, it doesn't return a value that is included in the empty set. NoReturn looks like a hack to me, whereas @noreturn tells me unambiguously that the compiler understands the meaning of the word too. And I see no value in having a first class type name for the bottom type.
I usually like mathematics, and I like Haskell too, but this doesn't seem to fit well with any of these. @noreturn should stay separate from any return values. In most cases, a @noreturn function returns Void, but I see no value in enforcing this.
I would prefer to keep the status quo and reject the proposal completely.

> 	* Is the problem being addressed significant enough to warrant a change to Swift?

No, there was no problem.

> 	* Does this proposal fit well with the feel and direction of Swift?

I don't think so.

> 	* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

No.

> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal, participated in earlier discussion and I think I understand where it is coming from. It is mathematically consistent, but so is the current @noreturn implementation as well. The current implementation is also more intuitive IMHO.

-Michael