[swift-evolution] [swift-evolution-announce] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[Félix Cloutier]

I'd like to point out that while NoReturn does indicate that the function can't return, this works because a function that can't return may well declare any return type that it likes, not necessarily just NoReturn.

It's confusing to see `@noreturn func foo() -> Int`, but it's not much better to have a `func foo() -> Int` that doesn't return either.

I don't think that `func foo() throws -> NoReturn` is much clearer either. Does foo always throw, does foo call exit, or does foo enter an endless loop?

It seems to me that we're only slightly moving the ambiguity, so I see no compelling reason to implement this proposal. That'll be a -1 here.

Félix

> Le 23 juin 2016 à 14:15:54, Jordan Rose via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> [Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md <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/ <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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160623/44c2ab83/attachment.html>