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

[Matthew Johnson]

> 	* What is your evaluation of the proposal?

I don’t have a firm opinion supporting or opposing this proposal.  I support the general direction but also share some of the concerns that have been raised.  

In particular, I believe this change is positive if the core team has an underlying vision for how bottom types will fit into Swift in the long term and this proposal is well aligned with that vision.  Specific issues to consider are whether Swift will have a single bottom type, support multiple bottom types, typealias different names to a single bottom type, etc.  I do find the `Exit`, `Abort` and `InfiniteLoop` examples interesting and would like to see the advantages and disadvantages of that direction explored a bit further.

It is also worthwhile to consider the bottom-related discussion that took place in the generalized existentials thread where it has been noted that types such as `Any<UIView, UIImage>` can be viewed as a bottom type, in which case we could allow formation of such a type (there was an interesting example of a set intersection function in that thread).  

However, I don’t think we should make this change if the future of bottom types in Swift is still uncertain.  As noted in the proposal, `@noreturn` functions are not that common and migration is trivial.  IMO the impact is small enough that a breaking change in this area the future should be acceptable.  That would be much better than making a change now and later discovering it doesn’t align with how we would like bottom types to fit into Swift more generally (possibly resulting in another breaking change anyway).

The proposal alludes to the idea that Swift may consider *any* uninhabited type to be a bottom type.  If that is indeed the generally intended direction this proposal aligns well.  In that case I would support the proposal but would still like to see a bit more bike shedding around the idea of using more specific names that specify *why* the function doesn’t return as suggested in the alternatives considered.

One final thought is that the `/*closed*/` aspect appears like it will still be implemented with compiler magic that knows that `NoReturn` is in fact closed.  It seems worth giving consideration to making `closed` language feature  that could be used more generally allowing us to remove the comment:

public closed enum NoReturn {}

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

I think introducing a bottom type is an interesting direction that certainly fits well with Swift.  I am not certain the specific `@noreturn` use case warrants an immediate change without having a more general plan in place.

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

Yes.

> 	* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Followed the discussion and review threads and read the final proposal in detail.

> 
> 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-announce mailing list
> swift-evolution-announce at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce