> > * What is your evaluation of the proposal? -1
The first “problem” given in the motivation is "As an orthogonal attribute of function types, its interaction must be specified with every other aspect of function types” Errr, well yes, of course. Why is it a problem that orthogonal concepts are more complex to implement than non orthogonal concepts? Pretending that @noreturn is just a return type is a hack coercing the type system to represent a concept that is not a type. That a function never returns is an attribute of the behaviour of the function not whatever it returns. The proposal is not answering the question “what is the best way to signify to the compiler and human reader that a function never returns” but “how do we signify to the compiler and human reader that a function never returns if we are not allowed to use the obvious self documenting solution of a function attribute?" Yes, it’s not only the compiler that needs to understand that a function never returns but human readers of the API too. The function attribute makes it crystal clear to humans what happens. The foo() -> NoReturn works nearly as well except that, at first glance, there appears to be nothing special about it. Everything else is less clear and I would resist those proposals strongly. The second “problem” given in the motivation is this: "Does `@noreturn throws` mean "cannot return normally, but can throw", or does it mean "cannot return at all?”” Why is this a problem? Clearly `@noreturn foo() throws` can throw an error or it wouldn’t say `throws`. There is no uncertainty here. The other problem given is this "Is @noreturn () -> Int allowed, and if so, does it behave differently from @noreturn () -> ()?" Personally I would say it should be allowed and does not return. The only difference between @noreturn function that return void and ones that return something else is that the ones that return something else can be used in expressions. However, I’m struggling to think of a use case for that. > * Is the problem being addressed significant enough to warrant a change > to Swift? I don’t agree that there’s a problem. > * Does this proposal fit well with the feel and direction of Swift? No, I think it certainly goes away from clarity. > * If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? I have used plenty of languages that have an attribute specifying noreturn behaviour but never one that expresses the concept as a type. > * How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? I’ve monitored the various threads about this. > > 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
