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

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to