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

[Jacob Bandes-Storch]

I also want to start a discussion (in a separate thread) about allowing
@noreturn functions to "return" any type, so that the unreachable code
checks can allow you to do things like "let value = fatalError()". For this
sort of thing, I think it's nice that noreturn is not an actual uninhabited
type, but has special meaning w.r.t. control flow, and could in fact be
part of the type signature.

Jacob

On Thu, Feb 25, 2016 at 2:51 PM, Radosław Pietruszewski <radexpl at gmail.com>
wrote:

> > On 25 Feb 2016, at 23:47, Joe Groff <jgroff at apple.com> wrote:
> >
> >
> >> On Feb 25, 2016, at 2:43 PM, Radosław Pietruszewski <radexpl at gmail.com>
> wrote:
> >>
> >>> On 25 Feb 2016, at 23:40, Joe Groff <jgroff at apple.com> wrote:
> >>>
> >>>
> >>>> On Feb 25, 2016, at 2:40 PM, Radosław Pietruszewski <
> radexpl at gmail.com> 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.
> >>>
> >>> -Joe
> >>
> >>
> >> The magic is somewhere else. Calling a @noreturn function allows you to
> do things you can’t otherwise do:
> >>
> >> func foo() -> Int {
> >>      fatalError()
> >> }
> >
> > I see. The unreachable code check arguably ought to also accept this if
> fatalError returns any uninhabited type, since it'll never be able return
> if that's the case.
> >
> > -Joe
>
> Would that actually be useful today? (i.e. aside from your idea) To me,
> having a NoReturn return type seems more magic and less obvious than an
> attribute.
>
> — Radek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160225/99701683/attachment.html>