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

Evolution Announcements
1

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:

  swift-evolution/0102-noreturn-bottom-type.md at master · apple/swift-evolution · GitHub

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?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * 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?

More information about the Swift evolution process is available at

  swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

-Chris Lattner
Review Manager

2

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.

···

On Jun 21, 2016, at 10:03 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

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

3

  * What is your evaluation of the proposal?

I like the idea, but not the name. I would prefer a more general name like `Never`.

If `NoReturn` becomes a universal bottom type, it's going to need a more universal name than `NoReturn` It's very narrow and specialized, so it's not appropriate for bottom types in other contexts; just think of the `NoReturn?` variable created by optional chaining, or the `[NoReturn]` array created by `map`. As soon as you take even the tiniest step away from a return value, the name doesn't really make sense anymore.

Therefore, I strongly suspect we'll have to change this name again in the future as `NoReturn` becomes a more powerful bottom type. I'm not really looking forward to changing `@noreturn` to `-> NoReturn` in Swift 3 and then changing it again to `-> Never` in Swift 4, so I think we should just do it here and now.

I also don't like the way `NoReturn` reads. It *is* understandable, but it bluntly disobeys type naming conventions by describing not the value being returned, but the member returning it. There are many sensible names we might have given `Void` if not for C—`Nothing`, `None`, `Empty`—but I don't think anybody would advocate for `EmptyReturn`. It just isn't an appropriate type name.

An attribute is an adjective describing a member, and `@noreturn` (or rather, `@nonreturning`) is a perfectly fine adjective to attach to a function, so the name works fine there. But a type is a *noun* describing a *value*, and `NoReturn` is not. You are trying to cram a square peg into a round hole.

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

Yes. Something should be done about `@noreturn`, and this basic approach is the most elegant one available.

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

The approach, but not the name. As I pointed out previously, it does not match naming conventions or even the general semantic meaning of a return type.

(Incidentally, another reason I like the idea of eventually having a subtype-of-all-types `Never` is that I think we should treat `UnsafePointer<Never>` as our "pointer of uncertain type" type. That is, `void *` should be imported to Swift as `UnsafePointer<Never>`. That would inherently prevent you from using the `pointee` property, and if you thought of `sizeof(Never)` as being infinite—a plausible interpretation since `Never` *could* be a subtype of a type of any size—it would also imply that pointer arithmetic or allocation of `Never` buffers would always overflow unless you were handling zero `Never`s.)

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

I've used other languages with equivalents to `@noreturn`, and I think the bottom return value approach will be an improvement on that.

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

Quick reading of the final proposal, but I've participated in much of the discussion about this feature.

···

--
Brent Royal-Gordon
Architechies

4

I have to say, this might be the most swifty of the swift proposals.

There's something about it that's elegant and beautiful, so big +1 from me.

I do think Never makes more sense, but I understand the clarity that NoReturn brings.

For a feature that most probably won't even use, maybe we could get away with it being Never...

Brandon

···

On Jun 21, 2016, at 1:03 PM, Chris Lattner <clattner@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?
   * Is the problem being addressed significant enough to warrant a change to Swift?
   * Does this proposal fit well with the feel and direction of Swift?
   * 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?

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

5

<https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md&gt;

Alternative names:

func infiniteLoop() -> _ { // Use an underscore instead?
    while true {}
}

func infiniteLoop() -> Unreachable {
    while true {}
}

func infiniteLoop() -> Unreachable<Void> {
    while true {}
}

Issues:

* Clang and Swift 2.2 allow non-returning functions to have a non-void return type.

* [LibraryEvolution.rst] @noreturn is a versioned attribute, so how will this proposal affect that design?

<https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst&gt;

-- Ben

6

  * What is your evaluation of the proposal?

+1, but I prefer Never (or other "generic" names), because that allows to
use this standard empty type for other purposes, such as Optional<Never>,
Either<T, Never>, throws Never.

  * Is the problem being addressed significant enough to warrant a

change to Swift?

I think yes. The proposal suggests a nice syntactic enhancement,
seamlessly integrating noreturn functions into the type system.

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

Swift?

Unified and minimalistic way of doing things - I think yes.

  * If you have used other languages or libraries with a similar

feature, how do you feel that this proposal

compares to those?

It is equivalent to Void type in Haskell, or Nothing in Scala.

  * How much effort did you put into your review? A glance, a quick

reading, or an in-depth study?

Between a quick reading and an in-depth study.

7

Although quite an obvious thing, I think import and export rules should be
written in the proposal.

Function with `noreturn` attribute returning type T will be imported to
Swift as a function returning empty type.

Function returning empty type will be exported from Swift as a `noreturn`
function returning `void`.

Also, throwing and rethrowing functions returning NoReturn CAN actually
return if they throw. It is equivalent to returning Either<NoReturn,

···

.

8

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.

···

On Tue, Jun 21, 2016 at 10:04 AM Chris Lattner <clattner@apple.com> wrote:

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

9

* What is your evaluation of the proposal?
-1. I don't believe that the '-> NoReturn' adequately expresses the behavior of a function. I view the construction 'T -> U' as a contract which states 'give me a T and I'll give you a U'. This stops making sense when U is NoReturn: 'give me a T and I'll give you a NoReturn (note: I won't actually give you a NoReturn)'! This construction also moves the behavioral information about the function to the end of the signature, where it is more easily missed.

* Is the problem being addressed significant enough to warrant a change to Swift?
I don't believe so. The main argument against @noreturn seems to be about complexity in the compiler, and an empty/bottom NoReturn type introduces complexity of its own with regards to subtyping, and special-casing the compiler to handle functions which return a particular type.

* Does this proposal fit well with the feel and direction of Swift?
Again, not IMO. Semantic modifications to function behavior in Swift are already well encompassed by attributes. These are a well established part of the language; if @noreturn were one of few attributes that were not wanted in the language, that would be a different matter, but attributes aren't going anywhere. Furthermore, I think that swift has mostly shied away from overly clever solutions in favor of clarity. I realize the desire in increasing the power of Swift's type system, but extending it to include properties which are arguably outside of the type system altogether doesn't seem like the right direction to go in.

* 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?
I read through the proposal and then the initial discussion on swift-evolution. Overall, I think that the @noreturn attribute better expresses that the behavior of the function is exceptional. NoReturn feels a bit too much like a clever hack to represent a type-that-is-not-a-type.

Freddy

On Jun 21, 2016, at 10:04 AM, Chris Lattner <clattner@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:

swift-evolution/0102-noreturn-bottom-type.md at master · apple/swift-evolution · GitHub

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?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* 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?

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

10

  * What is your evaluation of the proposal?

-1. I am for introducting a bottom type, but when it will be of more use and can be more universally designed. To me it feels like a hot-fix for something that isn't broken rather than a step forward for the language itself.

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

No.

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

Not yet. Introducing a bottom type is a good idea, but I feel that Swift isn't there yet to design it well and universally.

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

Scala has Nothing and it's a true bottom type. In regards to this proposal, Scala's solution is superior.

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

Read of the proposal + discussion.

···

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

11

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

···

Am 21.06.2016 um 19:03 schrieb Chris Lattner via swift-evolution <swift-evolution@swift.org>:

12

  * What is your evaluation of the proposal?

+1. This makes total sense. But I would recommend naming it “Never” for the same arguments as in the proposal.

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

Yes, it simplifies the language by replacing a rarely used attribute by an elegant solution from the type system. I also love how Never could be used with typed throws.

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

Yep: simplification and elegance.

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

A good read.

···

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

13

Curious on the possibility of something like the following to denote a no
return function?

func foo() -> !

...or mostly joking...

func foo() ->💥 (for thing like fatalError)
func foo() -> :arrows_clockwise:(for things like dispatch main)

Anyway I am generally -0.5 on this change without understanding if this
could be a bottom type and how that could work in the bigger picture.

-Shawn

···

On Tue, Jun 21, 2016 at 10:04 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?
        * Is the problem being addressed significant enough to warrant a
change to Swift?
        * Does this proposal fit well with the feel and direction of Swift?
        * 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?

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

14

  * 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

15

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

  * What is your evaluation of the proposal?

My feeling on this as a non-expert is that the attribute probably does the job well enough and that it is rare enough to not matter for virtually all Swift programmers. I’m less qualified to talk about the idea of a bottom type, but in reading the proposal a few times, I still can’t see what the point of that angle is from a uses-the-language-to-make-apps-rather-than-experiment-with-type-theory point of view.

In terms of complier implementation, I’m *entirely* unqualified, but I certainly understand the appeal to make things better/simpler/easier-to-maintain. If it helps to get rid of the attribute for this purpose, then okay, but personally I think I draw the line at declaring a single “official” NoReturn type (or Never or any other name). I don’t think that argument is compelling enough. The idea of declaring separate empty types based on circumstance is *way* more appealing to me and this was mentioned in the alternatives section. This seems like such a rare case that it would be worth it to have the extra clarity of intent from naming the return type accordingly - such as Exit or InfiniteLoop or whatever.

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

I’m not convinced, but I don’t work on the compiler. :)

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

I think having separate empty types that clearly illustrate the intent above and beyond a single NoReturn type is a more “Swifty" way to go.

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

n/a

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

Tracked the discussion some, when possible, read the proposal a few times.

l8r
Sean

16

  https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md

  * What is your evaluation of the proposal?

In terms of raw syntax, I like the idea of using an uninhabited types to indicate non-returning behavior.

I haven’t used a language with a ‘bottom’ type functionality, so I can’t evaluate that as an alternative.

I actually like the name ‘Never’ more than ‘NoReturn’, but thats mostly bike shedding. The one non-bikeshedding bit backing up the use of Never over NoReturn is that there is nothing in the language which prevents use of NoReturn in other contexts,e.g.:

func foo(_ n:NoReturn) {} // Compiles but is not callable
var a:Optional<NoReturn> = nil // works, but can never be .Some(x)

The one catch I see here is that even documentation tools will need to understand uninhabited types in order to represent behavior to a developer, but I believe there is already a strong push away from tools built on technologies which wouldn’t have access to that information (such as using regular expressions)

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

I think so - it eliminates what would need to be special rules around function declaration with @noescape, plus may allow for future subtype behaviors.

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

I think so

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

I haven’t used languages with bottom types before or with non-returning behavior indicated by use of certain types - I’ve only languages that annotate non-returning functions at the compiler level. However, it seems like a good way of eliminating redundant or possibly conflicting behavior as well as special rules, such as declaration of a @noreturn fatal(_ message:String)->Int, and covariance of using such a non-returning function as an argument

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

Quick reading of proposal, intermittent tracking of the discussion beforehand.

-DW

17

        * What is your evaluation of the proposal?

-1, we are introducing confusion between WHAT is returned and IF it returns

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

the assumption that the attribute was superfluous was wrong, for clarity
reasons. So there is no significant problem addressed

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

This proposal feels like someone wants to remove '@' from attributes: this
causes confusion. I may have defined a class with name NoReturn for a
different use.

        * How much effort did you put into your review? A glance, a quick

reading, or an in-depth study?

A quick reading.

Antoine

18

+1, I feel it will be very 'Swifty' to replace magical @noreturn attribute to clear special type(which then, later, probably could be used as bottom type). But I prefer "Never" as such type's name. IMO it's very easy to teach anyone that "Never" can't have instance of its type so `-> Never` means the func will not return and it reads clearly "returns never", so I believe it will not confuse one after first teching of meaning of Never type.

···

On 21.06.2016 20:03, Chris Lattner via swift-evolution 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?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * 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?

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

19

-1 for all the reasons already mentioned.
Although, if we end up accepting this anyway, FWIW I'd prefer "DoesNotReturn" or "NeverReturns" over "NoReturn" or "Never". They both read better to me, and their imperative names help make it clearer that something is different.

- Dave Sweeris

···

On Jun 21, 2016, at 12:03, Chris Lattner <clattner@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?
   * Is the problem being addressed significant enough to warrant a change to Swift?
   * Does this proposal fit well with the feel and direction of Swift?
   * 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?

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

20

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md ]

I am already on record as being against this proposal:

Just because it can be modelled as a type doesn’t mean it’s the best way to represent the concept. It feels like uniformity for uniformity’s sake.

func fatalError() -> NoReturn

@noreturn func fatalError()

The first one probably isn't too hard to explain to a learner. The second one probably doesn’t need an explanation.

(http://thread.gmane.org/gmane.comp.lang.swift.evolution/19958/\)

A few more thoughts: I don't think uninhabited types actually come up very often (though non-returning functions are also pretty rare). I'm not against supporting composition for actual uninhabited types, but I don't think composition of NoReturn/Never is particularly interesting. I don't find throws<Never> compelling enough to add language support for it, but maybe I just can't think of a case where you want to be generic over error types.

Jordan