On the other hand... The first is rather clever and beautiful looking...making it somewhat Swifty.
I never cared for annotations: - they make it look noisy - they seem like a "hack" rather than a true part of the standard library Also technically, @noreturn func fatalError() can be modeled as (I think?): @noreturn func fatalError() -> Void which doesn't make much sense. 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. Brandon > On Jun 7, 2016, at 8:21 PM, Jordan Rose via swift-evolution > <[email protected]> wrote: > > >>>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
