Re: [swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Chris Lattner via swift-evolution]

> On Jun 1, 2016, at 11:29 PM, Jacob Bandes-Storch  wrote:
> 
> On Wed, Jun 1, 2016 at 10:25 PM, Chris Lattner  > wrote:
> On Jun 1, 2016, at 9:28 PM, Jacob Bandes-Storch  > wrote:
>> 
>> On imported Objective-C API, the core team did a quick study of the Cocoa 
>> APIs and found that most closure/block parameters are escaping in practice.  
>> As such, the core team feels that it isn’t overly burdensome to ask that 
>> imported Objective-C APIs annotate their semantically noescape block 
>> parameters with the clang __attribute__((noescape)) attribute.
>> 
>> This part is what I proposed last year; still waiting on an update:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0012-add-noescape-to-public-library-api.md
>>  
>> 
>>  
> 
> The problem with that proposal, and the reason it is sitting around in limbo 
> is:
> 
> 1) it is prescriptive of a process “Audit system C/Objective-C libraries...", 
> not a proposal for a set of specific changes.
> 
> 2) swift-evolution isn’t the right place to propose changes for Foundation or 
> other APIs outside of the standard library.  
> 
> It has been stuck in a crack for a long time, and has no hope of getting 
> unstuck.  I think that at this point the right thing is to close it.  Is that 
> ok with you?
> 
> Okay, but is there any other way the community can have input on the set of 
> functions/methods that should be updated, and some visibility into 
> whether/when this will happen? It was my impression that Philippe was making 
> progress on this, but I hadn't heard any more for a while. (My concern would 
> be APIs getting missed due to lack of community input.)

At this point it is hard to say.  All I know is that the only process for this 
is to discuss it on the list (in which case many Apple folk will probably 
notice and make take it up on their own volition) or by filing a bug with 
bugreporter.apple.com  requesting it.  Neither 
of these approaches give you the transparency you seek into when or if it will 
happen.

I understand that this isn’t what you want to hear, but it’s just the reality 
that Apple’s general framework design and evolution is not governed by the 
swift-evolution process.

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

Re: [swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Trent Nadeau via swift-evolution]

I created a draft proposal to make `@noescape` the default and created a
new email thread with subject "[Proposal] Make non-escaping closures the
default".

On Thu, Jun 2, 2016 at 1:22 AM, Chris Lattner  wrote:

>
> On Jun 1, 2016, at 9:22 PM, Trent Nadeau  wrote:
>
> I'd like to write this proposal.
>
>
> Go for it!  Thanks,
>
> -Chris
>
>
> On Thu, Jun 2, 2016 at 12:11 AM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Jun 1, 2016, at 9:02 PM, Chris Lattner  wrote:
>> > 2) For noescape, the core team feels that the right solution is for
>> closure arguments to *default* to noescape, which means that the attribute
>> we should really need is @escaping.
>>
>> To provide some more details, this approach has the following advantages:
>>
>> - Most functional algorithms written in pure Swift will benefit because
>> they are naturally noescape.  The core team feels that this will reduce the
>> boilerplate involved with writing these algorithms.
>>
>> - The compiler has enough logic in it to provide a great QoI experience
>> when a developer doesn’t think about escaping, and tries to escape a
>> closure - it can provide a fixit that suggests adding @escaping.
>>
>> - Recent changes (to disallow escaping closures to close over an inout
>> parameter) are pushing the language to prefer noescape closures.  noescape
>> closures have also always been the preferred default, since they eliminate
>> a class of retain cycle issues.
>>
>> - "@autoclosure(escaping)" can be simplified and standardized to
>> "@autoclosure @escaping”
>>
>>
>> The two primary concerns with taking this direction were that it is would
>> adversely impact resilience, and that imported Objective-C APIs would be
>> too annoying to work with, because the compiler would have to be
>> conservative and assume they are escaping:
>>
>>
>>
>> On resilience, the concern with this approach is that an API may not
>> thinking about whether a closure parameter should be escaping or not, and
>> this behavior makes it possible that someone could write “V1” of an API and
>> not accidentally promise noescape semantics, but then need it in “V2” of
>> the same API.
>>
>> John McCall pointed out that resilience in the type system is different
>> than resilience in practice: An API changing to capture a closure and use
>> it long after it was originally passed is likely to break the clients
>> regardless of whether the type system captures this as an issue.  He argues
>> (and the argument is strong IMO) that it is *better* for resilient APIs to
>> default to @noescape, since that forces the author of V2 to think about
>> whether they are breaking their clients.  If they are doing something that
>> is “logically” noescape in their V2, then they can unsafe bitcast away the
>> escaping aspect of the closure.  This is better than changing the client’s
>> view of the API in any case.
>>
>>
>> On imported Objective-C API, the core team did a quick study of the Cocoa
>> APIs and found that most closure/block parameters are escaping in
>> practice.  As such, the core team feels that it isn’t overly burdensome to
>> ask that imported Objective-C APIs annotate their semantically noescape
>> block parameters with the clang __attribute__((noescape)) attribute.
>>
>>
>> I’m happy to write up this proposal, but won’t have cycles to do so for
>> several weeks.  If someone else wants to take it up, that would be great :-)
>>
>> -Chris
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
>
> --
> Trent Nadeau
>
>
>


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

Re: [swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Jacob Bandes-Storch via swift-evolution]

On Wed, Jun 1, 2016 at 10:25 PM, Chris Lattner  wrote:

> On Jun 1, 2016, at 9:28 PM, Jacob Bandes-Storch 
> wrote:
>
>
> On imported Objective-C API, the core team did a quick study of the Cocoa
>> APIs and found that most closure/block parameters are escaping in
>> practice.  As such, the core team feels that it isn’t overly burdensome to
>> ask that imported Objective-C APIs annotate their semantically noescape
>> block parameters with the clang __attribute__((noescape)) attribute.
>>
>
> This part is what I proposed last year; still waiting on an update:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0012-add-noescape-to-public-library-api.md
>
>
>
> The problem with that proposal, and the reason it is sitting around in
> limbo is:
>
> 1) it is prescriptive of a process “Audit system C/Objective-C
> libraries...", not a proposal for a set of specific changes.
>
> 2) swift-evolution isn’t the right place to propose changes for Foundation
> or other APIs outside of the standard library.
>
> It has been stuck in a crack for a long time, and has no hope of getting
> unstuck.  I think that at this point the right thing is to close it.  Is
> that ok with you?
>
> -Chris
>

Okay, but is there any other way the community can have input on the set of
functions/methods that should be updated, and some visibility into
whether/when this will happen? It was my impression that Philippe was
making progress on this, but I hadn't heard any more for a while. (My
concern would be APIs getting missed due to lack of community input.)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Chris Lattner via swift-evolution]

On Jun 1, 2016, at 9:28 PM, Jacob Bandes-Storch  wrote:
> 
> On imported Objective-C API, the core team did a quick study of the Cocoa 
> APIs and found that most closure/block parameters are escaping in practice.  
> As such, the core team feels that it isn’t overly burdensome to ask that 
> imported Objective-C APIs annotate their semantically noescape block 
> parameters with the clang __attribute__((noescape)) attribute.
> 
> This part is what I proposed last year; still waiting on an update:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0012-add-noescape-to-public-library-api.md
>  
> 
>  

The problem with that proposal, and the reason it is sitting around in limbo is:

1) it is prescriptive of a process “Audit system C/Objective-C libraries...", 
not a proposal for a set of specific changes.

2) swift-evolution isn’t the right place to propose changes for Foundation or 
other APIs outside of the standard library.  

It has been stuck in a crack for a long time, and has no hope of getting 
unstuck.  I think that at this point the right thing is to close it.  Is that 
ok with you?

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

Re: [swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Chris Lattner via swift-evolution]

> On Jun 1, 2016, at 9:22 PM, Trent Nadeau  wrote:
> 
> I'd like to write this proposal.

Go for it!  Thanks,

-Chris

> 
> On Thu, Jun 2, 2016 at 12:11 AM, Chris Lattner via swift-evolution 
> > wrote:
> On Jun 1, 2016, at 9:02 PM, Chris Lattner  > wrote:
> > 2) For noescape, the core team feels that the right solution is for closure 
> > arguments to *default* to noescape, which means that the attribute we 
> > should really need is @escaping.
> 
> To provide some more details, this approach has the following advantages:
> 
> - Most functional algorithms written in pure Swift will benefit because they 
> are naturally noescape.  The core team feels that this will reduce the 
> boilerplate involved with writing these algorithms.
> 
> - The compiler has enough logic in it to provide a great QoI experience when 
> a developer doesn’t think about escaping, and tries to escape a closure - it 
> can provide a fixit that suggests adding @escaping.
> 
> - Recent changes (to disallow escaping closures to close over an inout 
> parameter) are pushing the language to prefer noescape closures.  noescape 
> closures have also always been the preferred default, since they eliminate a 
> class of retain cycle issues.
> 
> - "@autoclosure(escaping)" can be simplified and standardized to 
> "@autoclosure @escaping”
> 
> 
> The two primary concerns with taking this direction were that it is would 
> adversely impact resilience, and that imported Objective-C APIs would be too 
> annoying to work with, because the compiler would have to be conservative and 
> assume they are escaping:
> 
> 
> 
> On resilience, the concern with this approach is that an API may not thinking 
> about whether a closure parameter should be escaping or not, and this 
> behavior makes it possible that someone could write “V1” of an API and not 
> accidentally promise noescape semantics, but then need it in “V2” of the same 
> API.
> 
> John McCall pointed out that resilience in the type system is different than 
> resilience in practice: An API changing to capture a closure and use it long 
> after it was originally passed is likely to break the clients regardless of 
> whether the type system captures this as an issue.  He argues (and the 
> argument is strong IMO) that it is *better* for resilient APIs to default to 
> @noescape, since that forces the author of V2 to think about whether they are 
> breaking their clients.  If they are doing something that is “logically” 
> noescape in their V2, then they can unsafe bitcast away the escaping aspect 
> of the closure.  This is better than changing the client’s view of the API in 
> any case.
> 
> 
> On imported Objective-C API, the core team did a quick study of the Cocoa 
> APIs and found that most closure/block parameters are escaping in practice.  
> As such, the core team feels that it isn’t overly burdensome to ask that 
> imported Objective-C APIs annotate their semantically noescape block 
> parameters with the clang __attribute__((noescape)) attribute.
> 
> 
> I’m happy to write up this proposal, but won’t have cycles to do so for 
> several weeks.  If someone else wants to take it up, that would be great :-)
> 
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> 
> -- 
> Trent Nadeau

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

Re: [swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Jacob Bandes-Storch via swift-evolution]

On Wed, Jun 1, 2016 at 9:11 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jun 1, 2016, at 9:02 PM, Chris Lattner  wrote:
> > 2) For noescape, the core team feels that the right solution is for
> closure arguments to *default* to noescape, which means that the attribute
> we should really need is @escaping.
>
> To provide some more details, this approach has the following advantages:
>
> - Most functional algorithms written in pure Swift will benefit because
> they are naturally noescape.  The core team feels that this will reduce the
> boilerplate involved with writing these algorithms.
>
> - The compiler has enough logic in it to provide a great QoI experience
> when a developer doesn’t think about escaping, and tries to escape a
> closure - it can provide a fixit that suggests adding @escaping.
>
> - Recent changes (to disallow escaping closures to close over an inout
> parameter) are pushing the language to prefer noescape closures.  noescape
> closures have also always been the preferred default, since they eliminate
> a class of retain cycle issues.
>
> - "@autoclosure(escaping)" can be simplified and standardized to
> "@autoclosure @escaping”
>
>
> The two primary concerns with taking this direction were that it is would
> adversely impact resilience, and that imported Objective-C APIs would be
> too annoying to work with, because the compiler would have to be
> conservative and assume they are escaping:
>
>
>
> On resilience, the concern with this approach is that an API may not
> thinking about whether a closure parameter should be escaping or not, and
> this behavior makes it possible that someone could write “V1” of an API and
> not accidentally promise noescape semantics, but then need it in “V2” of
> the same API.
>
> John McCall pointed out that resilience in the type system is different
> than resilience in practice: An API changing to capture a closure and use
> it long after it was originally passed is likely to break the clients
> regardless of whether the type system captures this as an issue.  He argues
> (and the argument is strong IMO) that it is *better* for resilient APIs to
> default to @noescape, since that forces the author of V2 to think about
> whether they are breaking their clients.  If they are doing something that
> is “logically” noescape in their V2, then they can unsafe bitcast away the
> escaping aspect of the closure.  This is better than changing the client’s
> view of the API in any case.
>
>
> On imported Objective-C API, the core team did a quick study of the Cocoa
> APIs and found that most closure/block parameters are escaping in
> practice.  As such, the core team feels that it isn’t overly burdensome to
> ask that imported Objective-C APIs annotate their semantically noescape
> block parameters with the clang __attribute__((noescape)) attribute.
>

This part is what I proposed last year; still waiting on an update:

https://github.com/apple/swift-evolution/blob/master/proposals/0012-add-noescape-to-public-library-api.md


>
>
> I’m happy to write up this proposal, but won’t have cycles to do so for
> several weeks.  If someone else wants to take it up, that would be great :-)
>
> -Chris
> ___
> 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] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Austin Zheng via swift-evolution]

+1. It would be great to get this reviewed and in for Swift 3.

Austin

> On Jun 1, 2016, at 9:22 PM, Trent Nadeau via swift-evolution 
>  wrote:
> 
> I'd like to write this proposal.
> 
> On Thu, Jun 2, 2016 at 12:11 AM, Chris Lattner via swift-evolution 
> > wrote:
> On Jun 1, 2016, at 9:02 PM, Chris Lattner  > wrote:
> > 2) For noescape, the core team feels that the right solution is for closure 
> > arguments to *default* to noescape, which means that the attribute we 
> > should really need is @escaping.
> 
> To provide some more details, this approach has the following advantages:
> 
> - Most functional algorithms written in pure Swift will benefit because they 
> are naturally noescape.  The core team feels that this will reduce the 
> boilerplate involved with writing these algorithms.
> 
> - The compiler has enough logic in it to provide a great QoI experience when 
> a developer doesn’t think about escaping, and tries to escape a closure - it 
> can provide a fixit that suggests adding @escaping.
> 
> - Recent changes (to disallow escaping closures to close over an inout 
> parameter) are pushing the language to prefer noescape closures.  noescape 
> closures have also always been the preferred default, since they eliminate a 
> class of retain cycle issues.
> 
> - "@autoclosure(escaping)" can be simplified and standardized to 
> "@autoclosure @escaping”
> 
> 
> The two primary concerns with taking this direction were that it is would 
> adversely impact resilience, and that imported Objective-C APIs would be too 
> annoying to work with, because the compiler would have to be conservative and 
> assume they are escaping:
> 
> 
> 
> On resilience, the concern with this approach is that an API may not thinking 
> about whether a closure parameter should be escaping or not, and this 
> behavior makes it possible that someone could write “V1” of an API and not 
> accidentally promise noescape semantics, but then need it in “V2” of the same 
> API.
> 
> John McCall pointed out that resilience in the type system is different than 
> resilience in practice: An API changing to capture a closure and use it long 
> after it was originally passed is likely to break the clients regardless of 
> whether the type system captures this as an issue.  He argues (and the 
> argument is strong IMO) that it is *better* for resilient APIs to default to 
> @noescape, since that forces the author of V2 to think about whether they are 
> breaking their clients.  If they are doing something that is “logically” 
> noescape in their V2, then they can unsafe bitcast away the escaping aspect 
> of the closure.  This is better than changing the client’s view of the API in 
> any case.
> 
> 
> On imported Objective-C API, the core team did a quick study of the Cocoa 
> APIs and found that most closure/block parameters are escaping in practice.  
> As such, the core team feels that it isn’t overly burdensome to ask that 
> imported Objective-C APIs annotate their semantically noescape block 
> parameters with the clang __attribute__((noescape)) attribute.
> 
> 
> I’m happy to write up this proposal, but won’t have cycles to do so for 
> several weeks.  If someone else wants to take it up, that would be great :-)
> 
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> 
> -- 
> Trent Nadeau
> ___
> 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] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Trent Nadeau via swift-evolution]

I'd like to write this proposal.

On Thu, Jun 2, 2016 at 12:11 AM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jun 1, 2016, at 9:02 PM, Chris Lattner  wrote:
> > 2) For noescape, the core team feels that the right solution is for
> closure arguments to *default* to noescape, which means that the attribute
> we should really need is @escaping.
>
> To provide some more details, this approach has the following advantages:
>
> - Most functional algorithms written in pure Swift will benefit because
> they are naturally noescape.  The core team feels that this will reduce the
> boilerplate involved with writing these algorithms.
>
> - The compiler has enough logic in it to provide a great QoI experience
> when a developer doesn’t think about escaping, and tries to escape a
> closure - it can provide a fixit that suggests adding @escaping.
>
> - Recent changes (to disallow escaping closures to close over an inout
> parameter) are pushing the language to prefer noescape closures.  noescape
> closures have also always been the preferred default, since they eliminate
> a class of retain cycle issues.
>
> - "@autoclosure(escaping)" can be simplified and standardized to
> "@autoclosure @escaping”
>
>
> The two primary concerns with taking this direction were that it is would
> adversely impact resilience, and that imported Objective-C APIs would be
> too annoying to work with, because the compiler would have to be
> conservative and assume they are escaping:
>
>
>
> On resilience, the concern with this approach is that an API may not
> thinking about whether a closure parameter should be escaping or not, and
> this behavior makes it possible that someone could write “V1” of an API and
> not accidentally promise noescape semantics, but then need it in “V2” of
> the same API.
>
> John McCall pointed out that resilience in the type system is different
> than resilience in practice: An API changing to capture a closure and use
> it long after it was originally passed is likely to break the clients
> regardless of whether the type system captures this as an issue.  He argues
> (and the argument is strong IMO) that it is *better* for resilient APIs to
> default to @noescape, since that forces the author of V2 to think about
> whether they are breaking their clients.  If they are doing something that
> is “logically” noescape in their V2, then they can unsafe bitcast away the
> escaping aspect of the closure.  This is better than changing the client’s
> view of the API in any case.
>
>
> On imported Objective-C API, the core team did a quick study of the Cocoa
> APIs and found that most closure/block parameters are escaping in
> practice.  As such, the core team feels that it isn’t overly burdensome to
> ask that imported Objective-C APIs annotate their semantically noescape
> block parameters with the clang __attribute__((noescape)) attribute.
>
>
> I’m happy to write up this proposal, but won’t have cycles to do so for
> several weeks.  If someone else wants to take it up, that would be great :-)
>
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



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

Re: [swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Chris Lattner via swift-evolution]

On Jun 1, 2016, at 9:02 PM, Chris Lattner  wrote:
> 2) For noescape, the core team feels that the right solution is for closure 
> arguments to *default* to noescape, which means that the attribute we should 
> really need is @escaping.

To provide some more details, this approach has the following advantages:

- Most functional algorithms written in pure Swift will benefit because they 
are naturally noescape.  The core team feels that this will reduce the 
boilerplate involved with writing these algorithms.

- The compiler has enough logic in it to provide a great QoI experience when a 
developer doesn’t think about escaping, and tries to escape a closure - it can 
provide a fixit that suggests adding @escaping.

- Recent changes (to disallow escaping closures to close over an inout 
parameter) are pushing the language to prefer noescape closures.  noescape 
closures have also always been the preferred default, since they eliminate a 
class of retain cycle issues.

- "@autoclosure(escaping)" can be simplified and standardized to "@autoclosure 
@escaping”


The two primary concerns with taking this direction were that it is would 
adversely impact resilience, and that imported Objective-C APIs would be too 
annoying to work with, because the compiler would have to be conservative and 
assume they are escaping:



On resilience, the concern with this approach is that an API may not thinking 
about whether a closure parameter should be escaping or not, and this behavior 
makes it possible that someone could write “V1” of an API and not accidentally 
promise noescape semantics, but then need it in “V2” of the same API.  

John McCall pointed out that resilience in the type system is different than 
resilience in practice: An API changing to capture a closure and use it long 
after it was originally passed is likely to break the clients regardless of 
whether the type system captures this as an issue.  He argues (and the argument 
is strong IMO) that it is *better* for resilient APIs to default to @noescape, 
since that forces the author of V2 to think about whether they are breaking 
their clients.  If they are doing something that is “logically” noescape in 
their V2, then they can unsafe bitcast away the escaping aspect of the closure. 
 This is better than changing the client’s view of the API in any case.


On imported Objective-C API, the core team did a quick study of the Cocoa APIs 
and found that most closure/block parameters are escaping in practice.  As 
such, the core team feels that it isn’t overly burdensome to ask that imported 
Objective-C APIs annotate their semantically noescape block parameters with the 
clang __attribute__((noescape)) attribute.


I’m happy to write up this proposal, but won’t have cycles to do so for several 
weeks.  If someone else wants to take it up, that would be great :-)

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

[swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Chris Lattner via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0097-negative-attributes.md

Hello Swift Community,

The review of SE-0097: "Normalizing naming for "negative" attributes" ran from 
May 24…30, 2016. The proposal is *rejected* for Swift 3.  

The core team agrees with the principle guiding the proposal (that negative 
attributes should start with “non” instead of “no”) and highly values 
standardized naming for attributes.  The community was lukewarm about 
“nonescaping” but pretty significantly opposed to “nonreturning”.

The core team discussed this at length and agreed that the problem identified 
by the proposal needs to be solved, but prefers to explore directions that 
would define away these attributes completely:


1) For noreturn, the core team prefers to explore a solution where a function 
can be declared as returning an non-constructable “bottom” type (e.g. an enum 
with zero cases).  This would lead to something like:

func abort() -> NoReturn { … }

This will require some new support in the compiler, but should flow better 
through the type system than @noreturn in function composition and other 
applications.  Joe Groff offered to write a proposal for this.


2) For noescape, the core team feels that the right solution is for closure 
arguments to *default* to noescape, which means that the attribute we should 
really need is @escaping.


Many thanks to Erica Sadun for driving this discussion and writing the 
proposal.  This was an important topic for the community and core team to 
re-evalute, and it was very effective at forcing progress.

-Chris Lattner
Review Manager

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