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

[Brandon Knope]

Sent from my iPad

> On Jun 8, 2016, at 5:59 AM, Jeremy Pereira <jeremy.j.pereira at googlemail.com> wrote:
> 
> 
>> 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. 

I knew I would regret using this word. I can do this too: "clever" is not necessarily bad either. (The very definition says "quick to understand, learn...". Seems pretty apt here)

> “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).

Of course it is subjective. Almost every reply in swift evolution is rooted in personal opinion. 

> “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 guess we need to tell this to Chris...who uses it quite often. "Swifty" IS a thing. It's just not 100% defined and constantly changing. 
> 
>> 
>> I never cared for annotations:
> 
> That’s a subjective opinion.

Of course...but isn't this where I share...my opinion?

> 
>> - they make it look noisy
> 
> How so?

@noreturn func test() -> Void
func test() -> Never

Objectively...it is less noisy by using less characters :P. 

Also, the function information seems somewhat lost with the heavy @ annotation (my opinion!). My eyes are immediately drawn to the annotation when looking at this signature. Is this good or bad? It's all subjective, but to me it makes this version noisier. 


> 
>> - 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.

That was kind of my point. Doesn't swift try to define almost everything in the standard library? It would be more Swifty!
> 
>> 
>> 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.

It's redundant. And why would a noreturn function have a return type? Maybe I'm missing a use case


> 
>> 
>> 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.
> 

This one was a stretch on my part, but I need to think a little more on this. 

Brandon 

> 
>>> 
>>> _______________________________________________
>>> 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
>