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

Evolution Announcements
1

Proposal link: swift-evolution/0097-negative-attributes.md at master · apple/swift-evolution · GitHub

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

2

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

···

On Jun 1, 2016, at 9:02 PM, Chris Lattner <clattner@apple.com> 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.

3

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.

Are you thinking in terms of a *real* bottom type—that is, a type which is the subtype of all types—or a fake bottom type which is simply an empty enum?

If you're thinking about a real bottom type, I wouldn't want to call it `NoReturn`, because the bottom type may end up playing a larger role in the language. Given our use of `Any`, the natural names for a bottom type are probably `All` (as the subtype of all types) or `None` (as a type with no instances). I do worry that those names are a little too short and attractive, though. `None` might be mistaken for `Void`; `All` might be mistaken for `Any`, and wouldn't make much sense when read as the return value of a function.

My best suggestion is `Never`. A function with a `Never` return type would read as "never returns":

  func abort() -> Never { … }

If it appeared in, say, a generic type, it would mean "never occurs":

  let result: Result<String, Never>

Flowing from that, we can end up with functions taking a `Never` parameter, which are never called:

  result.flatMapError { (_: Never) in fatalError("can't happen") }

Or `Never?` values, which are never `some`:

  let _: Never? = Result<String, Never>.error

(By the way, the return type of the force unwrap operator on a `Never?` is `Never`, which is just right: if you force unwrap a `Never?`, it will always trap, never return.)

The main issue I see with `Never` is that it's an adverb, not a noun. But the nouns all seem to have problems. And besides, the bottom type isn't so much a thing as a lack of a thing, isn't it? That's bound to have a slightly funky name.

···

--
Brent Royal-Gordon
Architechies

4

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

···

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 <clattner@apple.com> wrote:

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

5

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 <clattner@apple.com> 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

6

In terms of naming, I almost feel like “None” would be a better name for it as then it reads somewhat as the opposite of “Any” and that has a nice symmetry to me.

l8r
Sean

···

On Jun 2, 2016, at 4:04 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

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.

Are you thinking in terms of a *real* bottom type—that is, a type which is the subtype of all types—or a fake bottom type which is simply an empty enum?

If you're thinking about a real bottom type, I wouldn't want to call it `NoReturn`, because the bottom type may end up playing a larger role in the language. Given our use of `Any`, the natural names for a bottom type are probably `All` (as the subtype of all types) or `None` (as a type with no instances). I do worry that those names are a little too short and attractive, though. `None` might be mistaken for `Void`; `All` might be mistaken for `Any`, and wouldn't make much sense when read as the return value of a function.

My best suggestion is `Never`. A function with a `Never` return type would read as "never returns":

  func abort() -> Never { … }

If it appeared in, say, a generic type, it would mean "never occurs":

  let result: Result<String, Never>

Flowing from that, we can end up with functions taking a `Never` parameter, which are never called:

  result.flatMapError { (_: Never) in fatalError("can't happen") }

Or `Never?` values, which are never `some`:

  let _: Never? = Result<String, Never>.error

(By the way, the return type of the force unwrap operator on a `Never?` is `Never`, which is just right: if you force unwrap a `Never?`, it will always trap, never return.)

The main issue I see with `Never` is that it's an adverb, not a noun. But the nouns all seem to have problems. And besides, the bottom type isn't so much a thing as a lack of a thing, isn't it? That's bound to have a slightly funky name.

--
Brent Royal-Gordon
Architechies

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

7

+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 <swift-evolution@swift.org> wrote:

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 <mailto:swift-evolution@swift.org>> wrote:
On Jun 1, 2016, at 9:02 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> 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 <mailto: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

8

I'd like to write this proposal.

Go for it! Thanks,

-Chris

···

On Jun 1, 2016, at 9:22 PM, Trent Nadeau <tanadeau@gmail.com> wrote:

On Thu, Jun 2, 2016 at 12:11 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jun 1, 2016, at 9:02 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> 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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

9

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

···

On Jun 1, 2016, at 9:28 PM, Jacob Bandes-Storch <jtbandes@gmail.com> 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

10

In terms of naming, I almost feel like “None” would be a better name for it as then it reads somewhat as the opposite of “Any” and that has a nice symmetry to me.

+ 1. Although the inverse of “None” is really “All” (as in “all or none”). I’m not necessarily suggesting we use “All”, just pointing out the linguistic relationship.

That said, I do believe we should *consider* alternatives names for “Any” as part of the discussion of the name for a bottom type. It would be nice symmetry if we found names for the top and bottom types that are inverses of each other.

···

On Jun 2, 2016, at 9:52 AM, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:

l8r
Sean

On Jun 2, 2016, at 4:04 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

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.

Are you thinking in terms of a *real* bottom type—that is, a type which is the subtype of all types—or a fake bottom type which is simply an empty enum?

If you're thinking about a real bottom type, I wouldn't want to call it `NoReturn`, because the bottom type may end up playing a larger role in the language. Given our use of `Any`, the natural names for a bottom type are probably `All` (as the subtype of all types) or `None` (as a type with no instances). I do worry that those names are a little too short and attractive, though. `None` might be mistaken for `Void`; `All` might be mistaken for `Any`, and wouldn't make much sense when read as the return value of a function.

My best suggestion is `Never`. A function with a `Never` return type would read as "never returns":

  func abort() -> Never { … }

If it appeared in, say, a generic type, it would mean "never occurs":

  let result: Result<String, Never>

Flowing from that, we can end up with functions taking a `Never` parameter, which are never called:

  result.flatMapError { (_: Never) in fatalError("can't happen") }

Or `Never?` values, which are never `some`:

  let _: Never? = Result<String, Never>.error

(By the way, the return type of the force unwrap operator on a `Never?` is `Never`, which is just right: if you force unwrap a `Never?`, it will always trap, never return.)

The main issue I see with `Never` is that it's an adverb, not a noun. But the nouns all seem to have problems. And besides, the bottom type isn't so much a thing as a lack of a thing, isn't it? That's bound to have a slightly funky name.

--
Brent Royal-Gordon
Architechies

_______________________________________________
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

11

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 <clattner@apple.com> wrote:

On Jun 1, 2016, at 9:22 PM, Trent Nadeau <tanadeau@gmail.com> 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 <clattner@apple.com> 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

12

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

···

On Wed, Jun 1, 2016 at 10:25 PM, Chris Lattner <clattner@apple.com> wrote:

On Jun 1, 2016, at 9:28 PM, Jacob Bandes-Storch <jtbandes@gmail.com> > 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

13

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 <Feedback Assistant; 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

···

On Jun 1, 2016, at 11:29 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:

On Wed, Jun 1, 2016 at 10:25 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
On Jun 1, 2016, at 9:28 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> 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.)