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

[Tony Allevato]

On Tue, Jun 21, 2016 at 10:04 AM Chris Lattner <clattner at apple.com> 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. Encoding this behavior in the return type of a function is far more
natural than having an attribute that exists outside the type system. I
also don't think that it unduly restricts us from expanding its use into a
"true" bottom type in the future.

I prefer the name "Never" because it reads cleanly (func foo(...) -> Never
== "function foo takes ... as arguments and returns never"), and it works
well in some of the possible future scenarios described in the proposal.

While "Never" feels slightly less suitable as a true bottom type name,
other alternatives like "None" or "Nothing" feel too close to existing
Swift concepts, like the "none" case in Optional. You can still argue that
"Never" works here though, in the sense that you will "Never" have a value
of that type.



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

Yes. The benefits both in user case and in simplifying the language
implementation are strong.



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

Yes, this moves Swift in the direction of consistency that other proposals
have done.



>         * 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?
>

Read the proposal and participated in some of the earlier discussions.


>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160621/eb769c3a/attachment.html>