[swift-evolution] [Draft] Change @noreturn to unconstructible return type

[Jeremy Pereira]

> On 8 Jun 2016, at 03:10, Brandon Knope via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On the other hand...
> 
> The first is rather clever and beautiful looking...making it somewhat Swifty. 

“Clever” is not necessarily good. “Clever” implies cleverness is needed to understand it. 

“Beautiful” is a subjective concept. Personally, I think a computer language construct is beautiful if it conveys the intent with complete clarity. By my criteria the @noreturn attribute is beautiful and the -> Never return type is ugly (or at least less beautiful).

“Swifty” is a nebulous concept that nobody has defined and thus means different things to different people. It seems to me that “it’s not Swifty” is used mostly to try to shut down debate when reasoned arguments are thin on the ground.  


> 
> I never cared for annotations:

That’s a subjective opinion.

> - they make it look noisy 

How so?

> - they seem like a "hack" rather than a true part of the standard library

Annotations aren’t part of the standard library are they? I thought they were part of the language.

> 
> Also technically, 
> 
> @noreturn func fatalError()
> 
> can be modeled as (I think?):
> @noreturn func fatalError() -> Void
> 
> which doesn't make much sense. 

In what way does it not make sense? Theoretically there’s no problem with specifying a return type for a noreturn function.

> 
> Also, could this fix this issue:
> "That said, you can’t override a function or method that is marked with the noreturnattribute with a function or method that is not. Similar rules apply when you implement a protocol method in a conforming type."
>  
> Overriding a method without this as an attribute could allow this. I'm not sure if this is something people would need though or if it even makes sense. 

It doesn’t make sense. If you have a protocol or a base class with an @noreturn method, and you could override it with a method that does return, then code using the protocol or base class that assumes that the method does not return as the API contract says will be surprised when, after dispatching the call, it returns.


>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution