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

[James Froggatt]

I support this proposal for similar reasons.

> covariance of using such a non-returning function as an argument

This is the key feature of this proposal.

In the earlier discussion, someone gave an example of a Runnable protocol, having one function which returns an associated type, and a second which takes that type as a parameter. By having the first return Never, the second function cannot be called, just as the first function cannot return.

As this currently are, @noreturn functions could already return an unconstructable Never type, but instead return the empty tuple (AKA Void or Unit). This proposal just enforces this safety measure by promoting it to a language feature, making the language safer and more powerful as a result.

The arguments that ‘-> Never’ could look like just another return type are valid, but I think we have a false dichotomy here. This proposal suggests that the compiler can detect unconstructable types, and infer when functions return (or can be called) from that. Once we have that power, it's a relatively simple matter to enforce a keyword in these situations (like @noreturn), while still having all the safety to be gained from this proposal.

I can see programmers from other languages with a void keyword arguing things like ‘it's not a real type’, ‘it looks like a return value’ about Swift's ‘Void’, yet Swift nevertheless models Void as a type, and has much more powerful function types as a result. This proposal seems very much in the same nature.

------------ Begin Message ------------ 
Group: gmane.comp.lang.swift.evolution 
MsgID: <48A7178C-FA85-409D-B6C3-5EF18CDFAB37 at alkaline-solutions.com> 

>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



------------- End Message ------------- 



From James F