> On Jun 7, 2016, at 12:49, Michael Peternell via swift-evolution > <[email protected]> wrote: > >> >> Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution >> <[email protected]>: >> >>> On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution >>> <[email protected]> wrote: >>> >>>> I disagree. We are discussing how to annotate a function in some way so >>>> that the compiler knows that the code following it will never be executed >>>> *and* so a human who reads the declaration knows that it does not return. >>>> “Never" is a poor choice for that. Never what? Never return? Never use >>>> this function? Never say never again? >>> >>> "Never return". That's why it's in the return type slot, right after the >>> `->`. If you read it out loud, you'll read "returns Never", which is >>> exactly correct. >>> >>> NoReturn, on the other hand, does *not* read well in that slot: "returns >>> NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it makes >>> no sense whatsoever *as a type name*. >> >> But it’s *not* a type. You’ll never have an instance of it. Since it’s not a >> type name, it doesn’t make sense that it needs to look like one. What it is >> doing is telling you something about the behavior of the function itself, >> not its return value. Its return value, if there were one, is irrelevant, >> since the function, by its very nature, will never even get to the point >> where it would return it. Either it’s going to kill the app via a fatalError >> or something, or we have something like dispatch_main() which will keep >> executing until the program stops, and one way or another, it won’t return. >> >> For that reason, frankly, I don’t understand why we want to change this from >> being an attribute, which seems to me the more natural and logical choice to >> describe this behavior. If we *do* have to change it, though, NoReturn >> conveys the most clearly to the reader what it does. > > +1 for @noreturn > We don't have to change it. > We have to keep it.
I strongly agree. 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() -> Never @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. Jordan
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
