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: <[email protected]> >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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
