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