[swift-evolution] Idea: change "@noreturn func f()" to "func f() noreturn"

[Howard Lovatt]

The NoReturn type would have to be a bottom type so that a method returning
an X could be overridden with NoReturn. I think that would be compiler
magic in Swift rather than an enum you couldn't instantiate. +1 to changing
to a type rather than an annotation, it reads a lot better to me.

On Saturday, 27 February 2016, Joe Groff via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Feb 25, 2016, at 11:39 PM, Jean-Daniel Dupas <mailing at xenonium.com
> <javascript:;>> wrote:
> >
> >
> >> Le 25 févr. 2016 à 23:40, Joe Groff via swift-evolution <
> swift-evolution at swift.org <javascript:;>> a écrit :
> >>
> >>
> >>> On Feb 25, 2016, at 2:40 PM, Radosław Pietruszewski <radexpl at gmail.com
> <javascript:;>> wrote:
> >>>
> >>> Ah, that’s a neat idea! Not sure it’s an improvement though to have a
> magic type that changes how the compiler treats your method, rather than a
> rather explicit *attribute* on the method…
> >>
> >> There's no magic. If you can't construct a value of your return type,
> you can't return.
> >
> > Just curious about how you would implement such function if there is no
> compile magic ?
> >
> > How do you tell the compiler is it not an error that your function never
> return while it is declared to return something ?
>
> The compiler can tell statically that a closed, empty enum type is
> uninhabited, and thereby figure out that it's impossible for a function
> returning an uninhabited type can't possibly return.
>
> -Joe
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


-- 
-- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160227/77e156f1/attachment.html>