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

[Thorsten Seitz via swift-evolution]

+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 swift-evolution 
> :
> 
> 
>>* 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 replacing a rarely used attribute by an 
> elegant solution from the type system. I also love how Never could be used 
> with typed throws.
> 
>>* Does this proposal fit well with the feel and direction of Swift?
> 
> Yep: simplification and elegance.
> 
>>* If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> No.
> 
>>* How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> A good read.
> 
>> 
>> More information about the Swift evolution process is available at
>> 
>>https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

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 
>  wrote:
> 
> 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 next() -> Either
> }
> 
> Result can be used for information why the stream has stopped.
> Calling next() after it returns Result is undefined behaviour.
> 
> You can easily see that Iterator is a special case of Stream
> with Result = ().
> 
> Algorithms on IteratorWithResult should not drop the result:
> 
> func forEach(stream: inout S,
>block: (S.Element) -> ())
>-> S.Result
>where S: Stream
> 
> We can split our Stream nicely:
> 
> func split(stream: inout S,
>  take: Int)
>  -> TakePrefixStream
>  where S: Stream
> 
> TakePrefixStream.Result is also a Stream, so to process two parts of 
> stream differently, we do:
> 
> split(s, take: 10).forEach(calledOnFirstTen).forEach(calledOnOthers)
> 
> In the same spirit, we can split a stream into 3 or N parts.
> Note that split itself does not take any elements from the Stream,
> everything is lazy.
> 
> You've already noticed where Never has its place.
> If a stream is infinite, we use Result = Never.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Anton Zhilin via swift-evolution]

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 next() -> Either
}

Result can be used for information why the stream has stopped.
Calling next() after it returns Result is undefined behaviour.

You can easily see that Iterator is a special case of Stream
with Result = ().

Algorithms on IteratorWithResult should not drop the result:

func forEach(stream: inout S,
block: (S.Element) -> ())
-> S.Result
where S: Stream

We can split our Stream nicely:

func split(stream: inout S,
  take: Int)
  -> TakePrefixStream
  where S: Stream

TakePrefixStream.Result is also a Stream, so to process two parts of 
stream differently, we do:

split(s, take: 10).forEach(calledOnFirstTen).forEach(calledOnOthers)

In the same spirit, we can split a stream into 3 or N parts.
Note that split itself does not take any elements from the Stream,
everything is lazy.

You've already noticed where Never has its place.
If a stream is infinite, we use Result = Never.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jeremy Pereira via swift-evolution]

> 
>   * 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 concepts are 
more complex to implement than non orthogonal concepts? 

Pretending that @noreturn is just a return type is a hack coercing the type 
system to represent a concept that is not a type. That a function never returns 
is an attribute of the behaviour of the function not whatever it returns. The 
proposal is not answering the question “what is the best way to signify to the 
compiler and human reader that a function never returns” but “how do we signify 
to the compiler and human reader that a function never returns if we are not 
allowed to use the obvious self documenting solution of a function attribute?"

Yes, it’s not only the compiler that needs to understand that a function never 
returns but human readers of the API too. The function attribute makes it 
crystal clear to humans what happens. The foo() -> NoReturn works nearly as 
well except that, at first glance, there appears to be nothing special about 
it. Everything else is less clear and I would resist those proposals strongly.

The second “problem” given in the motivation is this:

"Does `@noreturn throws` mean "cannot return normally, but can throw", or does 
it mean "cannot return at all?””

Why is this a problem? Clearly `@noreturn foo() throws` can throw an error or 
it wouldn’t say `throws`. There is no uncertainty here.

The other problem given is this "Is @noreturn () -> Int  allowed, and if so, 
does it behave differently from @noreturn () -> ()?"

Personally I would say it should be allowed and does not return. The only 
difference between @noreturn function that return void and ones that return 
something else is that the ones that return something else can be used in 
expressions. However, I’m struggling to think of a use case for that.  



>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

I don’t agree that there’s a problem.

>   * Does this proposal fit well with the feel and direction of Swift?

No, I think it certainly goes away from clarity.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

I have used plenty of languages that have an attribute specifying noreturn 
behaviour but never one that expresses the concept as a type.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

I’ve monitored the various threads about this.


> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[James Froggatt via swift-evolution]

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 second which takes 
that type as a parameter. By having the first return Never, the second function 
cannot be called, just as the first function cannot return.

As this currently are, @noreturn functions could already return an 
unconstructable Never type, but instead return the empty tuple (AKA Void or 
Unit). This proposal just enforces this safety measure by promoting it to a 
language feature, making the language safer and more powerful as a result.

The arguments that ‘-> Never’ could look like just another return type are 
valid, but I think we have a false dichotomy here. This proposal suggests that 
the compiler can detect unconstructable types, and infer when functions return 
(or can be called) from that. Once we have that power, it's a relatively simple 
matter to enforce a keyword in these situations (like @noreturn), while still 
having all the safety to be gained from this proposal.

I can see programmers from other languages with a void keyword arguing things 
like ‘it's not a real type’, ‘it looks like a return value’ about Swift's 
‘Void’, yet Swift nevertheless models Void as a type, and has much more 
powerful function types as a result. This proposal seems very much in the same 
nature.

 Begin Message  
Group: gmane.comp.lang.swift.evolution 
MsgID: <48a7178c-fa85-409d-b6c3-5ef18cdfa...@alkaline-solutions.com> 

>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 ‘bottom’ type functionality, so I can’t 
evaluate that as an alternative.

I actually like the name ‘Never’ more than ‘NoReturn’, but thats mostly bike 
shedding. The one non-bikeshedding bit backing up the use of Never over 
NoReturn is that there is nothing in the language which prevents use of 
NoReturn in other contexts,e.g.:

func foo(_ n:NoReturn) {}  // Compiles but is not callable
var a:Optional = nil // works, but can never be .Some(x)

The one catch I see here is that even documentation tools will need to 
understand uninhabited types in order to represent behavior to a developer, but 
I believe there is already a strong push away from tools built on technologies 
which wouldn’t have access to that information (such as using regular 
expressions)

>* Is the problem being addressed significant enough to warrant a change to 
>Swift?

I think so - it eliminates what would need to be special rules around function 
declaration with @noescape, plus may allow for future subtype behaviors.

>* Does this proposal fit well with the feel and direction of Swift?

I think so

>* If you have used other languages or libraries with a similar feature, how do 
>you feel that this proposal compares to those?

I haven’t used languages with bottom types before or with non-returning 
behavior indicated by use of certain types - I’ve only languages that annotate 
non-returning functions at the compiler level. However, it seems like a good 
way of eliminating redundant or possibly conflicting behavior as well as 
special rules, such as declaration of a @noreturn fatal(_ message:String)->Int, 
and covariance of using such a non-returning function as an argument

>* How much effort did you put into your review? A glance, a quick reading, or 
>an in-depth study?

Quick reading of proposal, intermittent tracking of the discussion beforehand.

-DW



- End Message - 



From James F
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Waite via swift-evolution]

>   
> 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 ‘bottom’ type functionality, so I can’t 
evaluate that as an alternative.

I actually like the name ‘Never’ more than ‘NoReturn’, but thats mostly bike 
shedding. The one non-bikeshedding bit backing up the use of Never over 
NoReturn is that there is nothing in the language which prevents use of 
NoReturn in other contexts,e.g.:

func foo(_ n:NoReturn) {}  // Compiles but is not callable
var a:Optional = nil // works, but can never be .Some(x)

The one catch I see here is that even documentation tools will need to 
understand uninhabited types in order to represent behavior to a developer, but 
I believe there is already a strong push away from tools built on technologies 
which wouldn’t have access to that information (such as using regular 
expressions)

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

I think so - it eliminates what would need to be special rules around function 
declaration with @noescape, plus may allow for future subtype behaviors.

>   * Does this proposal fit well with the feel and direction of Swift?

I think so

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

I haven’t used languages with bottom types before or with non-returning 
behavior indicated by use of certain types - I’ve only languages that annotate 
non-returning functions at the compiler level. However, it seems like a good 
way of eliminating redundant or possibly conflicting behavior as well as 
special rules, such as declaration of a @noreturn fatal(_ message:String)->Int, 
and covariance of using such a non-returning function as an argument

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick reading of proposal, intermittent tracking of the discussion beforehand.

-DW


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Sean Heber via swift-evolution]

> 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 evaluation of the proposal?

My feeling on this as a non-expert is that the attribute probably does the job 
well enough and that it is rare enough to not matter for virtually all Swift 
programmers. I’m less qualified to talk about the idea of a bottom type, but in 
reading the proposal a few times, I still can’t see what the point of that 
angle is from a 
uses-the-language-to-make-apps-rather-than-experiment-with-type-theory point of 
view.

In terms of complier implementation, I’m *entirely* unqualified, but I 
certainly understand the appeal to make things 
better/simpler/easier-to-maintain. If it helps to get rid of the attribute for 
this purpose, then okay, but personally I think I draw the line at declaring a 
single “official” NoReturn type (or Never or any other name). I don’t think 
that argument is compelling enough. The idea of declaring separate empty types 
based on circumstance is *way* more appealing to me and this was mentioned in 
the alternatives section. This seems like such a rare case that it would be 
worth it to have the extra clarity of intent from naming the return type 
accordingly - such as Exit or InfiniteLoop or whatever.


>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

I’m not convinced, but I don’t work on the compiler. :)


>   * Does this proposal fit well with the feel and direction of Swift?

I think having separate empty types that clearly illustrate the intent above 
and beyond a single NoReturn type is a more “Swifty" way to go.


>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

n/a


>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Tracked the discussion some, when possible, read the proposal a few times.

l8r
Sean

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Anton Zhilin via swift-evolution]

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 implemented under a different name.
> 
> Excuse me, but it seems to me you might be missing one important point 
about the proposal: there's going to be no “the” bottom type — any enum 
with no cases would act as one if the proposal is accepted. The standard 
library would just happen name one to stand as the preferred default.
> In other words (unless I'm mistaken), no compiler magic proposed about 
a specific (`NoReturn` or `Never`) empty enum. All the proposed “magic” 
would be about uninhabited types (link to specific section in the 
proposal) as return types.
> 
> — Pyry

I think a good design would still be to use a single "main" empty type 
throughout the standard library.
Let's look at a silly example:

func swapReturnThrow(block: () throws E -> T) throws T -> E where 
T: ErrorType, E: ErrorType

If T is NoReturn or E is NoThrow then swapReturnThrow would return 
NoThrow and throw NoReturn. These scoped empty types were pulled to a 
scope where they make no sense.

This problem does not occur with a single "main" empty type. But then we 
must decide on its name now.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Pyry Jahkola via swift-evolution]

> 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 name.

Excuse me, but it seems to me you might be missing one important point about 
the proposal: there's going to be no “the” bottom type — any enum with no cases 
would act as one if the proposal is accepted. The standard library would just 
happen name one to stand as the preferred default.

In other words (unless I'm mistaken), no compiler magic proposed about a 
specific (`NoReturn` or `Never`) empty enum. All the proposed “magic” would be 
about uninhabited types 

 (link to specific section in the proposal) as return types.

— Pyry

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Antoine Cœur via swift-evolution]

>
> * 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 clarity
reasons. So there is no significant problem addressed


> * Does this proposal fit well with the feel and direction of Swift?
>
This proposal feels like someone wants to remove '@' from attributes: this
causes confusion. I may have defined a class with name NoReturn for a
different use.

* How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
A quick reading.

Antoine
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

> 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
>>> attribute to clear special type(which then, later, probably could be
>>> used as bottom type).
>> 
>> That's the problem of this proposal IMHO. It feels like a quick-fix for
>> the attribute, but is something that is likely to be changed once a real
>> bottom type is introduced. I'd suggest waiting until the language is
>> ready to introduce a real bottom type that can be used more universally
>> (generics, ...).
> 
> As I understand the situation: proposal is for changing @noreturn to 
> Never(actually NoReturn, which I don't like) for Swift 3.0 to make code 
> breaking changes *now*. Then, after 3.0, we can *extend* meaning of Never(if 
> we decided) without breaking changes for @noreturn.
> 
> Do you want to say that 'Never' can't be then used as bottom type if we'll 
> introduce it now just as special return type instead of @noreturn?

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 name.

> 
>> 
>>> 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`
>>> means the func will not return and it reads clearly "returns never",
>>> so I believe it will not confuse one after first teching of meaning of
>>> Never type.
>>> 
>>> On 21.06.2016 20:03, 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 here:
 
 https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md
 
 
 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
 
 https://lists.swift.org/mailman/listinfo/swift-evolution
 
 or, if you would like to keep your feedback private, directly to the
 review manager.
 
 What goes into a review?
 
 The goal of the review process is to improve the proposal under
 review through constructive criticism and contribute to the
 direction of Swift. When writing your review, here are some
 questions you might want to answer in your review:
 
 * What is your evaluation of the proposal? * Is the problem being
 addressed significant enough to warrant a change to Swift? * Does
 this proposal fit well with the feel and direction of Swift? * If
 you have used other languages or libraries with a similar feature,
 how do you feel that this proposal compares to those? * How much
 effort did you put into your review? A glance, a quick reading, or
 an in-depth study?
 
 More information about the Swift evolution process is available at
 
 https://github.com/apple/swift-evolution/blob/master/process.md
 
 Thank you,
 
 -Chris Lattner Review Manager
 
 ___ swift-evolution
 mailing list swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
 
>>> ___ swift-evolution
>>> mailing list swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

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 type).


That's the problem of this proposal IMHO. It feels like a quick-fix for
the attribute, but is something that is likely to be changed once a real
bottom type is introduced. I'd suggest waiting until the language is
ready to introduce a real bottom type that can be used more universally
(generics, ...).


As I understand the situation: proposal is for changing @noreturn to 
Never(actually NoReturn, which I don't like) for Swift 3.0 to make code 
breaking changes *now*. Then, after 3.0, we can *extend* meaning of 
Never(if we decided) without breaking changes for @noreturn.


Do you want to say that 'Never' can't be then used as bottom type if we'll 
introduce it now just as special return type instead of @noreturn?





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`
means the func will not return and it reads clearly "returns never",
so I believe it will not confuse one after first teching of meaning of
Never type.

On 21.06.2016 20:03, 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 here:

https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md



Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at


https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under
review through constructive criticism and contribute to the
direction of Swift. When writing your review, here are some
questions you might want to answer in your review:

* What is your evaluation of the proposal? * Is the problem being
addressed significant enough to warrant a change to Swift? * Does
this proposal fit well with the feel and direction of Swift? * If
you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those? * How much
effort did you put into your review? A glance, a quick reading, or
an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner Review Manager

___ swift-evolution
mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


___ swift-evolution
mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution




___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Rimmington via swift-evolution]

> 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":



I suggested using an underscore, but a named type could work better with 
optional chaining:



-- Ben

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

> 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 proposal IMHO. It feels like a quick-fix for the 
attribute, but is something that is likely to be changed once a real bottom 
type is introduced. I'd suggest waiting until the language is ready to 
introduce a real bottom type that can be used more universally (generics, ...).

>  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` means the func 
> will not return and it reads clearly "returns never", so I believe it will 
> not confuse one after first teching of meaning of Never type.
> 
> On 21.06.2016 20:03, 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 here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and contribute to the direction of Swift. 
>> When writing your review, here are some questions you might want to answer 
>> in your review:
>> 
>>  * What is your evaluation of the proposal?
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  * Does this proposal fit well with the feel and direction of Swift?
>>  * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>>  https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

+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` 
means the func will not return and it reads clearly "returns never", so I 
believe it will not confuse one after first teching of meaning of Never type.


On 21.06.2016 20:03, 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 here:


https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and contribute to the direction of Swift. When writing 
your review, here are some questions you might want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Shawn Erickson via swift-evolution]

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
could be a bottom type and how that could work in the bigger picture.


-Shawn

On Tue, Jun 21, 2016 at 10:04 AM Chris Lattner via swift-evolution <
swift-evolution@swift.org> 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 here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a
> change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> * [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 subtype-of-all-types bottom type, then you would 
always be able to change any return type to Never. There may be ABI reasons 
that this couldn't be supported—for instance, a Boolean existential has a 
different representation than a concrete Bool struct—but I believe it would be 
semantically sound.

(Of course, if you had to write `Any` instead of `Boolean`, the fact 
that you couldn't replace it with `Bool` would be a little more straightforward 
to understand...)

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

>   * 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 replacing a rarely used attribute by an 
elegant solution from the type system. I also love how Never could be used with 
typed throws.

>   * Does this proposal fit well with the feel and direction of Swift?

Yep: simplification and elegance.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

No.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

A good read.

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kevin Nattinger via swift-evolution]

> 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 
> here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?

-1. 
noreturn is logically and fundamentally an attribute of a function, not a 
return (pseudo-)type, and it should continue to be expressed that way. 
If the idea of `@noreturn foo() -> Int` being valid really bothers you so much, 
just forbid functions declared noreturn from having a specified return type 
(maybe even an explicit `()`/`Void`).


>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

No.
There is no problem being solved. noreturn as an attribute is clear, 
precedented, and easily searchable. Furthermore, I feel the proposal doesn’t 
even fix most of the “issues” it brings up in the motivation section— `-> 
NoReturn throws` is no more clear than `@noreturn throws`, and `compose(exit, 
getExitCode)` is no more clear declared `-> NoReturn` than `@noreturn`.  And it 
introduces ambiguity of its own. If someone defines their own empty enum, does 
`func foo() -> MyEmptyEnum` get the same treatment as NoReturn? If not, why is 
it special cased? If so, 

>   * Does this proposal fit well with the feel and direction of Swift?

No.
We want swift to be intuitive. IMO, `@noreturn` is way more intuitive than 
saying you’ll return something that you can’t actually follow through with. And 
 everywhere else such a contradiction would be a compiler error. 

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

It unnecessarily breaks from tradition. The C family uses noreturn attributes. 
I haven’t seen anyone bring up language where noreturn is achieved in this 
manner.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Followed the email chain, thoroughly read the proposal.

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michael Peternell via swift-evolution]

> 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:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?

-1
I like the common assumption that when a function returns a type T, it means 
that the function returns a value of type T. A function that does *not* return, 
does not return a value of type T, for any T. Specifically, it doesn't return a 
value that is included in the empty set. NoReturn looks like a hack to me, 
whereas @noreturn tells me unambiguously that the compiler understands the 
meaning of the word too. And I see no value in having a first class type name 
for the bottom type.
I usually like mathematics, and I like Haskell too, but this doesn't seem to 
fit well with any of these. @noreturn should stay separate from any return 
values. In most cases, a @noreturn function returns Void, but I see no value in 
enforcing this.
I would prefer to keep the status quo and reject the proposal completely.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

No, there was no problem.

>   * Does this proposal fit well with the feel and direction of Swift?

I don't think so.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

No.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Read the proposal, participated in earlier discussion and I think I understand 
where it is coming from. It is mathematically consistent, but so is the current 
@noreturn implementation as well. The current implementation is also more 
intuitive IMHO.

-Michael

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

>   * 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 problem being addressed significant enough to warrant a change 
> to Swift?

No.

>   * Does this proposal fit well with the feel and direction of Swift?

Not yet. Introducing a bottom type is a good idea, but I feel that Swift isn't 
there yet to design it well and universally.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

Scala has Nothing and it's a true bottom type. In regards to this proposal, 
Scala's solution is superior.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Read of the proposal + discussion.

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Anton Zhilin via swift-evolution]

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` 
function returning `void`.

Also, throwing and rethrowing functions returning NoReturn CAN actually 
return if they throw. It is equivalent to returning Either.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Anton Zhilin via swift-evolution]

>   * 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 a 
change to Swift?

I think yes. The proposal suggests a nice syntactic enhancement, 
seamlessly integrating noreturn functions into the type system.

>   * Does this proposal fit well with the feel and direction of 
Swift?

Unified and minimalistic way of doing things - I think yes.

>   * If you have used other languages or libraries with a similar 
feature, how do you feel that this proposal
> compares to those?

It is equivalent to Void type in Haskell, or Nothing in Scala.

>   * How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

Between a quick reading and an in-depth study.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Rimmington via swift-evolution]

Alternative names:

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

func infiniteLoop() -> Unreachable {
while true {}
}

func infiniteLoop() -> Unreachable {
while true {}
}

Issues:

* Clang and Swift 2.2 allow non-returning functions to have a non-void return 
type.

* [LibraryEvolution.rst] @noreturn is a versioned attribute, so how will this 
proposal affect that design?



-- Ben

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution