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