[Proposal:
https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md
]
I am already on record as being against this proposal:
> Just because it can be modelled as a type doesn’t mean it’s the best way to
> represent the concept. It feels like uniformity for uniformity’s sake.
>
> func fatalError() -> NoReturn
>
> @noreturn func fatalError()
>
> The first one probably isn't too hard to explain to a learner. The second one
> probably doesn’t need an explanation.
(http://thread.gmane.org/gmane.comp.lang.swift.evolution/19958/)
A few more thoughts: I don't think uninhabited types actually come up very
often (though non-returning functions are also pretty rare). I'm not against
supporting composition for actual uninhabited types, but I don't think
composition of NoReturn/Never is particularly interesting. I don't find
throws<Never> compelling enough to add language support for it, but maybe I
just can't think of a case where you want to be generic over error types.
Jordan
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
