Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

+1 from me as well for the same reasons including a strong preference for naming it "Never" to allow using it in other places than just as return type. This would make it easy to turn it into a real bottom type in the future. -Thorsten > Am 22.06.2016 um 01:12 schrieb David Hart via

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

Although i understand the intention, there are existing designs in other languages offering proven better alternatives. So i would not leave thinking that a compelling case for 'Never' has been made. > On Jun 24, 2016, at 6:01 PM, Anton Zhilin via swift-evolution >

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

https://github.com/apple/swift-evolution/blob/master/proposals/0102- noreturn-bottom-type.md I can think of at least one example of using Never. Suppose Stream protocol that returns a value at the end: protocol Stream { associatedtype Element associatedtype Result mutable func

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

> > * What is your evaluation of the proposal? -1 The first “problem” given in the motivation is "As an orthogonal attribute of function types, its interaction must be specified with every other aspect of function types” Errr, well yes, of course. Why is it a problem that orthogonal

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

I support this proposal for similar reasons. > covariance of using such a non-returning function as an argument This is the key feature of this proposal. In the earlier discussion, someone gave an example of a Runnable protocol, having one function which returns an associated type, and a

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

> > https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md > > * What is your evaluation of the proposal? In terms of raw syntax, I like the idea of using an uninhabited types to indicate non-returning behavior. I haven’t used a language with a

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

> The review of "SE-0102: Remove @noreturn attribute and introduce an empty > NoReturn type" begins now and runs through June 27. The proposal is available > here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md > > * What is your

Re: [swift-evolution] [Review] SE-0102: Remove noreturn attribute and introduce an empty NoReturn type

Pyry Jahkola via swift-evolution writes: > On 22 Jun 2016, at 14:47, Charlie Monroe via swift-evolution wrote: > > I can live with Never. But the proposed NoReturn is a single-case solution and would eventually require a code-breaking change anyway were the bottom type

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

> On 22 Jun 2016, at 14:47, Charlie Monroe via swift-evolution > wrote: > > I can live with Never. But the proposed NoReturn is a single-case solution > and would eventually require a code-breaking change anyway were the bottom > type implemented under a different

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

> > * What is your evaluation of the proposal? > -1, we are introducing confusion between WHAT is returned and IF it returns > * Is the problem being addressed significant enough to warrant a > change to Swift? > the assumption that the attribute was superfluous was wrong, for

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

> On Jun 22, 2016, at 1:42 PM, Vladimir.S wrote: > > On 22.06.2016 14:15, Charlie Monroe wrote: >> >>> On Jun 22, 2016, at 12:41 PM, Vladimir.S via swift-evolution >>> wrote: >>> >>> +1, I feel it will be very 'Swifty' to replace magical @noreturn

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

On 22.06.2016 14:15, Charlie Monroe wrote: On Jun 22, 2016, at 12:41 PM, Vladimir.S via swift-evolution wrote: +1, I feel it will be very 'Swifty' to replace magical @noreturn attribute to clear special type(which then, later, probably could be used as bottom

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

> On 22 Jun 2016, at 02:15, Shawn Erickson via swift-evolution > wrote: > > Curious on the possibility of something like the following to denote a no > return function? > > func foo() -> ! See "Diverging functions" in "The Rust Programming Language":

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

> On Jun 22, 2016, at 12:41 PM, Vladimir.S via swift-evolution > wrote: > > +1, I feel it will be very 'Swifty' to replace magical @noreturn attribute to > clear special type(which then, later, probably could be used as bottom type). That's the problem of this

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

+1, I feel it will be very 'Swifty' to replace magical @noreturn attribute to clear special type(which then, later, probably could be used as bottom type). But I prefer "Never" as such type's name. IMO it's very easy to teach anyone that "Never" can't have instance of its type so `-> Never`

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

Curious on the possibility of something like the following to denote a no return function? func foo() -> ! ...or mostly joking... func foo() -> (for thing like fatalError) func foo() -> (for things like dispatch main) Anyway I am generally -0.5 on this change without understanding if this

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

> * [LibraryEvolution.rst] @noreturn is a versioned attribute, so how will this > proposal affect that design? If library evolution permitted you to change a return type into one of its subtypes (for instance, to change an NSObject return into an NSResponder return), and if Never were a

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

> * What is your evaluation of the proposal? +1. This makes total sense. But I would recommend naming it “Never” for the same arguments as in the proposal. > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes, it simplifies the language by

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

> On Jun 21, 2016, at 10:03 AM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0102: Remove @noreturn attribute and introduce an empty > NoReturn type" begins now and runs through June 27. The proposal is available >

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

> Am 21.06.2016 um 19:03 schrieb Chris Lattner via swift-evolution > : > > Hello Swift community, > > The review of "SE-0102: Remove @noreturn attribute and introduce an empty > NoReturn type" begins now and runs through June 27. The proposal is available > here: >

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

> * What is your evaluation of the proposal? -1. I am for introducting a bottom type, but when it will be of more use and can be more universally designed. To me it feels like a hot-fix for something that isn't broken rather than a step forward for the language itself. > * Is the

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

Although quite an obvious thing, I think import and export rules should be written in the proposal. Function with `noreturn` attribute returning type T will be imported to Swift as a function returning empty type. Function returning empty type will be exported from Swift as a `noreturn`

Re: [swift-evolution] [Review] SE-0102: Remove noreturn attribute and introduce an empty NoReturn type

> * What is your evaluation of the proposal? +1, but I prefer Never (or other "generic" names), because that allows to use this standard empty type for other purposes, such as Optional, Either, throws Never. > * Is the problem being addressed significant enough to warrant

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

Alternative names: func infiniteLoop() -> _ { // Use an underscore instead? while true {} } func infiniteLoop() -> Unreachable { while true {} } func infiniteLoop() -> Unreachable { while

[swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

Hello Swift community, The review of "SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type" begins now and runs through June 27. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md Reviews are