[Review] SE-0086: Drop NS Prefix in Swift Foundation

Evolution Announcements
21

We (you) shouldn't remove the NS prefixes from most of the classes in
the proposal. I agree with the reasons the other naysayers have given,
but I'll try to restate them in my own words.

Swift needs a better namespace/import system before these classes
should lose the NS prefix. Right now, you cannot just import one name
from a module. (If you think you can, try typing “import
Foundation.NSDate; NSPort.self” into the REPL.) Therefore we should be
selective about what loses the NS prefix.

You can. Try `import class Foundation.NSDate`. :)
That’s said there are cases which it won’t work. Say if you try to import CGFloat from UIKit/CoreGraphics, it seems a few conformances are lost, e.g. FloatLiteralConvertible.

···

On 17 May 2016, at 9:36 AM, Rob Mayoff via swift-evolution <swift-evolution@swift.org> wrote:

For any type, some fraction of programs need to mention the type by
name in order to justify a prefixless name. What should that threshold
be? Fifty percent? Ten percent? Five percent? String and Int and a
bunch of other types in the standard library can pass a reasonable
threshold. What fraction of programs mention NSTask? NSPort? NSHost?
NSScanner?

For any name, some fraction of programs would want to use that term
for a program-specific type different than the Foundation type. What
fraction is high enough to justify prefixing the Foundation type name?
E.g. are there enough datebook programs that think "Calendar" should
mean the user's schedule of events, so that Foundation shouldn't claim
the generic term "Calendar"? How about "Timer"? "Task"? "Port"?
"Host"?

What fraction of these Foundation types would have a substantially
different API if they were designed from scratch in the age of Swift
with the experience of Foundation? Example: NSDate. Looking at each of
JodaTime, NodaTime, and boost::date_time, I see a type representing a
calendar date (e.g. 2016-05-16) with no associated time of day. I've
seen and answered enough questions on stackoverflow to know that iOS
programmers want a type like that. A from-scratch Swift date/time
library would be justified in having such a type, and "Date" would be
a great name for that type (with a prefix or nested in another type,
unless Swift gets a better namespace/import system). NSDate represents
the same thing as CFAbsoluteTime, and should have a name more
representative of that.

I just don't see the benefit of stripping the NS prefix from most of
the types in Foundation, given the state of those types and the state
of Swift.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

22

Unless I'm mistaken, NSURL is not among the types being renamed in this
proposal?

···

On Mon, May 9, 2016 at 19:06 Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote:

I’m afraid I generally have to agree with this criticism. For types like
NSURL which would make sense to become value types in the future, dropping
the prefix does seem as if it would put constraints on future growth.

I do think the enum hoisting is great, though, and if it were in a
separate proposal I’d definitely +1 it.

Charles

> On May 9, 2016, at 6:57 PM, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote:
>
>> • What is your evaluation of the proposal?
>
> I support the enum hoisting and case renaming, but not the dropping of
the "NS" prefix quite this widely, for several reasons:
>
> 1. I agree with the critique that "NSCoder" and its ilk should retain
their "NS" prefix because they represent something very specific to
Foundation, not some general concept of a "coder". ("JSONSerialization", on
the other hand, *is* something quite generic.)
>
> 2. I think the "NS" prefixes may be a valuable indicator of which types
are values and which are references. (For this to be the case, we might
need to drop some NS prefixes from certain enums.)
>
> 3. I am wholly unconvinced by the arguments in the "Keep NS on future
value types" section.
>
> Another proposal (I'm behind, so I'm not sure if it's been accepted)
suggests that we add a value-typed `URL` to Foundation. Think about what
would happen if that proposal were deferred to Swift 4: `NSURL` would be
renamed to `URL` in Swift 3, and then Swift 4 would want to use `URL` for
something else. At that point, we have several choices, none of them very
nice:
>
> * Rename uses of `URL` back to `NSURL`, only one version after making
the opposite change. Note that this doesn't only mean migrating code, but
also developers' understanding of the frameworks—people will misread code
for a while.
>
> * Choose a different name for the new value-typed `URL`, like `URLValue`
or `URI` or something. The preferred type then gets a suboptimal name.
>
> * Deprecate the `URL` name, encourage use of `NSURL` instead, and delay
the introduction of the new `URL` for a version or two while the
deprecation works its magic. Now we've slowed down the evolution of the
language.
>
> Any of these seems like a huge own goal next to the alternative of
simply leaving all (or most) NS prefixes in place, at least until we feel
the main work of adding value types to Foundation is complete.
>
>> • Is the problem being addressed significant enough to warrant a
change to Swift?
>
> Sure, Foundation needs some cleanup. Just not *this* cleanup.
>
>> • Does this proposal fit well with the feel and direction of Swift?
>
> Yes and no. I worry it'll slow the adoption of value types by
Foundation, which would not be a good thing.
>
>> • 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?
>
> Quick reading, I suppose.
>
> --
> 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

23

I second Matthew’s points. I believe dropping NS- is more harmful than helpful, especially for the future. People have been using Foundation with the prefix for decades, so I don’t think there’s a longing need that will make using it in Swift unbearable. It has an older Objective-C flavoured approach, relying heavily on classes, run loops, key value observing (e.g. NSOperation), exceptions, and notifications. I think its philosophy will stand out more than its NS- prefix. Even if many classes become value types, it feels more like a port.

I think for something to be so central as the recommended ‘foundational’ library for Swift, it carries too much baggage, which is unfortunate in the light of Swift’s radical eagerness to reject unnecessary legacy.

Many Foundation classes expect NSObject subclasses for delegates and for key value coding & observing. Key value observing requires on-the-fly subclassing at run time, something which goes strongly against Swift’s philosophy AFAIK.

Foundation is in some cases a wrapper around underlying technologies such as GCD, because years ago an Objective-C wrapper was seen as a more friendly, more safe, and a more familiar object-oriented approach. With Swift we have the power to make those technologies themselves more friendly, safe, and familiar with modernisations such as the current proposal for libdispatch. Extensions allow us to add properties and methods directly to the native types.

NSURL has methods such as .getResourceValue(_:forKey:) that involve mutable state.

I think removing the prefixes will take valuable real estate for types such as ‘URL’ and ‘Data’, which instead can have new replacements made, focused on the use-cases of only Swift. I think DispatchData could be a fine choice for ‘Data’, and has the strong benefit that it bridges to NSData on Darwin.

Perhaps you missed it, but SE-0069 adds corresponding value types for URL and Data, among others.

- Tony

···

On May 12, 2016, at 1:32 AM, Patrick Smith via swift-evolution <swift-evolution@swift.org> wrote:

I fully support the idea of improving Foundation, and of there being a Linux-compatible version. I don’t support it being as first class as the standard library or libdispatch, and don’t support removing the NS prefixes.

Patrick

On 11 May 2016, at 1:36 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

What is your evaluation of the proposal?

I very much support hoisting types, updating enumerations, and updating the NSStringEncoding constants.

I do not support dropping NS on type level names. Dropping the 2 character prefix is a very small benefit and it comes with very real costs. I believe unprefixed top level names should not be taken without a manual review of the API design.

Types which will be value types in the future are obvious candidates for redesign but are not the only types whose API would benefit by human consideration and Swiftification. Keeping the NS prefix until this happens recognizes that the Swiftification of Foundation is a work in progress. It will give us more options in the future that don’t involve breaking changes.

It will also serve as a signal to developers about what kinds of APIs should be considered idiomatic in Swift. If we want developers to learn how to distinguish idiomatic Swift, our API guidelines, etc from Objective-C mappings we need to provide some cues. I believe name prefixes are a good way to do this.

I hope that we will move forward with most of this proposal while keeping the NS prefix for top-level names.

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

Yes, but we need to do this carefully, deliberately and in a way that we won’t regret in the future. I believe several parts of the proposal are warranted, but the namesake “drop NS prefix” portion should deferred until each type receives manual consideration and possibly redesign.

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

Mostly yes. However, taking top-level unprefixed names without a process of Swiftification does not.

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

I think this question is N/A for this proposal.

I hesitate in saying this, but I think the best comparison to consider is the origin of Foundation and Cocoa themselves. They are fantastic Objective-C APIs. If they had originated by wrapping pre-existing APIs written in a different language with different idioms and then incrementally enhanced I wonder if they may have been less fantastic.

I believe reserving unprefixed top-level names for manually designed, idiomatic types is the path for Swift that avoids this risk altogether and gives us the best chance possible at an incredible, idiomatic set of libraries.

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

I participated in the discussion, read the proposal, and carefully considered the consequences of each piece.

More information about the Swift evolution process is available at

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

-Doug Gregor

Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org <mailto:swift-evolution-announce@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

24

Hi Tony,

Thanks for the response! As Kevin said:

“And if done right, the swiftified types can operate without Foundation at all”

This is why I think DispatchData would be superior to NSData, as NSData brings along all the rest of Foundation, whereas the entire Dispatch library looks like a great fit for Swift.

In fact, won’t Foundation require Dispatch as a dependency? So there’s already a doubling there if it is.

I think Dispatch is much more native than Foundation, and would vote to have its Dispatch- prefixes removed rather than Foundation remove its NS- ones.

Patrick

···

On 13 May 2016, at 5:06 AM, Tony Parker <anthony.parker@apple.com> wrote:

On May 12, 2016, at 1:32 AM, Patrick Smith via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I second Matthew’s points. I believe dropping NS- is more harmful than helpful, especially for the future. People have been using Foundation with the prefix for decades, so I don’t think there’s a longing need that will make using it in Swift unbearable. It has an older Objective-C flavoured approach, relying heavily on classes, run loops, key value observing (e.g. NSOperation), exceptions, and notifications. I think its philosophy will stand out more than its NS- prefix. Even if many classes become value types, it feels more like a port.

I think for something to be so central as the recommended ‘foundational’ library for Swift, it carries too much baggage, which is unfortunate in the light of Swift’s radical eagerness to reject unnecessary legacy.

Many Foundation classes expect NSObject subclasses for delegates and for key value coding & observing. Key value observing requires on-the-fly subclassing at run time, something which goes strongly against Swift’s philosophy AFAIK.

Foundation is in some cases a wrapper around underlying technologies such as GCD, because years ago an Objective-C wrapper was seen as a more friendly, more safe, and a more familiar object-oriented approach. With Swift we have the power to make those technologies themselves more friendly, safe, and familiar with modernisations such as the current proposal for libdispatch. Extensions allow us to add properties and methods directly to the native types.

NSURL has methods such as .getResourceValue(_:forKey:) that involve mutable state.

I think removing the prefixes will take valuable real estate for types such as ‘URL’ and ‘Data’, which instead can have new replacements made, focused on the use-cases of only Swift. I think DispatchData could be a fine choice for ‘Data’, and has the strong benefit that it bridges to NSData on Darwin.

Perhaps you missed it, but SE-0069 adds corresponding value types for URL and Data, among others.

- Tony

I fully support the idea of improving Foundation, and of there being a Linux-compatible version. I don’t support it being as first class as the standard library or libdispatch, and don’t support removing the NS prefixes.

Patrick

On 11 May 2016, at 1:36 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

What is your evaluation of the proposal?

I very much support hoisting types, updating enumerations, and updating the NSStringEncoding constants.

I do not support dropping NS on type level names. Dropping the 2 character prefix is a very small benefit and it comes with very real costs. I believe unprefixed top level names should not be taken without a manual review of the API design.

Types which will be value types in the future are obvious candidates for redesign but are not the only types whose API would benefit by human consideration and Swiftification. Keeping the NS prefix until this happens recognizes that the Swiftification of Foundation is a work in progress. It will give us more options in the future that don’t involve breaking changes.

It will also serve as a signal to developers about what kinds of APIs should be considered idiomatic in Swift. If we want developers to learn how to distinguish idiomatic Swift, our API guidelines, etc from Objective-C mappings we need to provide some cues. I believe name prefixes are a good way to do this.

I hope that we will move forward with most of this proposal while keeping the NS prefix for top-level names.

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

Yes, but we need to do this carefully, deliberately and in a way that we won’t regret in the future. I believe several parts of the proposal are warranted, but the namesake “drop NS prefix” portion should deferred until each type receives manual consideration and possibly redesign.

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

Mostly yes. However, taking top-level unprefixed names without a process of Swiftification does not.

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

I think this question is N/A for this proposal.

I hesitate in saying this, but I think the best comparison to consider is the origin of Foundation and Cocoa themselves. They are fantastic Objective-C APIs. If they had originated by wrapping pre-existing APIs written in a different language with different idioms and then incrementally enhanced I wonder if they may have been less fantastic.

I believe reserving unprefixed top-level names for manually designed, idiomatic types is the path for Swift that avoids this risk altogether and gives us the best chance possible at an incredible, idiomatic set of libraries.

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

I participated in the discussion, read the proposal, and carefully considered the consequences of each piece.

More information about the Swift evolution process is available at

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

-Doug Gregor

Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org <mailto:swift-evolution-announce@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

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

25

This sounds like a good idea.

-Matt

···

On May 10, 2016, at 03:43, Geordie Jay via swift-evolution <swift-evolution@swift.org> wrote:

Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

What is your evaluation of the proposal?

Personally I’m a -1; I’d prefer to see the NS prefix remain on types that have been translated automatically with minimal human interaction, in favour of dropping the prefix for types that have received more attention to establish a Swift-ier style, but migrating these into a new module instead.

I strongly agree with keeping NS prefix on API that has not been ‘Swiftified'. First step, achieve functional equivalence with Darwin APIs. Second step, systematically improve Foundation to the point where it feels like this fundamental part of the language is as easy to use and idiomatic as the standard library itself. At that point I’d be very much for dropping the prefixes.

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

Since it’s a basic API that most developers will be interacting with then yes, even though the change is fairly minor, it definitely bears consideration.

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

Yes and no. Prefixing types with NS definitely isn’t very Swift-y, but at the same time this is why I’d like to keep the current convention for existing (unchanged) types, as it makes it much clearer that these are things that weren’t originally designed for Swift and thus won’t behave quite as you might expect.

Completely agree

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

I’ve worked in languages where libraries had different styles of name-spacing, and while it was annoying to have a mixture, I think it was fine, especially for libraries that are older, as the prefix name-spacing style makes it absolutely clear that this is an older API.

Yes, we should be clear this is an older API, also to add motivation on introducing a more modern one (even if at first it just wraps Foundation with a more Swift-like API)

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

Quick read of the proposal, kept an eye on the discussion leading up to it though.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

26

Unless I'm mistaken, NSURL is not among the types being renamed in this proposal?

It is not, because it's already receiving a value-type equivalent. But types like `NSAttributedString`, which the Foundation team eventually intends to provide value-type equivalents for, *are* in the proposal. I'm merely illustrating the problem by using a type which we've already decided will get a value-type equivalent.

···

--
Brent Royal-Gordon
Architechies

27

Got it. In that case, count me in as +1 for most of the proposal but -1 on
AttributedString and its ilk. I agree with you and others that types which
are slated to receive the URL/NSURL treatment shouldn't go through an
interim renaming dance.

···

On Mon, May 9, 2016 at 20:53 Brent Royal-Gordon <brent@architechies.com> wrote:

> Unless I'm mistaken, NSURL is not among the types being renamed in this
proposal?

It is not, because it's already receiving a value-type equivalent. But
types like `NSAttributedString`, which the Foundation team eventually
intends to provide value-type equivalents for, *are* in the proposal. I'm
merely illustrating the problem by using a type which we've already decided
will get a value-type equivalent.

--
Brent Royal-Gordon
Architechies

28

I meant to say that it sounds like a good idea to leave the ’NS’ prefix on types that were auto-translated, and remove it from those that have been rewritten by hand for swift.

-Matt

···

On May 16, 2016, at 21:24, Matt Whiteside <mwhiteside.dev@gmail.com> wrote:

This sounds like a good idea.

-Matt

On May 10, 2016, at 03:43, Geordie Jay via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

What is your evaluation of the proposal?

Personally I’m a -1; I’d prefer to see the NS prefix remain on types that have been translated automatically with minimal human interaction, in favour of dropping the prefix for types that have received more attention to establish a Swift-ier style, but migrating these into a new module instead.

I strongly agree with keeping NS prefix on API that has not been ‘Swiftified'. First step, achieve functional equivalence with Darwin APIs. Second step, systematically improve Foundation to the point where it feels like this fundamental part of the language is as easy to use and idiomatic as the standard library itself. At that point I’d be very much for dropping the prefixes.

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

Since it’s a basic API that most developers will be interacting with then yes, even though the change is fairly minor, it definitely bears consideration.

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

Yes and no. Prefixing types with NS definitely isn’t very Swift-y, but at the same time this is why I’d like to keep the current convention for existing (unchanged) types, as it makes it much clearer that these are things that weren’t originally designed for Swift and thus won’t behave quite as you might expect.

Completely agree

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

I’ve worked in languages where libraries had different styles of name-spacing, and while it was annoying to have a mixture, I think it was fine, especially for libraries that are older, as the prefix name-spacing style makes it absolutely clear that this is an older API.

Yes, we should be clear this is an older API, also to add motivation on introducing a more modern one (even if at first it just wraps Foundation with a more Swift-like API)

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

Quick read of the proposal, kept an eye on the discussion leading up to it though.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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

29

I don’t think the API of types have to be bulletproof from the start, but it shouldn’t have core usage limitations based on Objective C. One example would be if I have to deal with NSNumber/NSString/NSArray/NSDictionary to fully use the API, such as NSAttributedString or NSError.

The issue is that Foundation is both the objective-c compatibility base and the cross-platform foundational library for Swift. These goals conflict. Without an idea of how the Swift flavor of Foundation will evolve in the future to deal with this conflict, it is hard to evaluate this other than saying “will be confusing why some Objective-C things have prefixes and others don’t” and “will cause conflicts with non-Apple foundational libraries”.

-DW

···

On May 17, 2016, at 7:41 AM, Matt Whiteside via swift-evolution <swift-evolution@swift.org> wrote:

I meant to say that it sounds like a good idea to leave the ’NS’ prefix on types that were auto-translated, and remove it from those that have been rewritten by hand for swift.

-Matt

On May 16, 2016, at 21:24, Matt Whiteside <mwhiteside.dev@gmail.com <mailto:mwhiteside.dev@gmail.com>> wrote:

This sounds like a good idea.

-Matt

On May 10, 2016, at 03:43, Geordie Jay via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

What is your evaluation of the proposal?

Personally I’m a -1; I’d prefer to see the NS prefix remain on types that have been translated automatically with minimal human interaction, in favour of dropping the prefix for types that have received more attention to establish a Swift-ier style, but migrating these into a new module instead.

I strongly agree with keeping NS prefix on API that has not been ‘Swiftified'. First step, achieve functional equivalence with Darwin APIs. Second step, systematically improve Foundation to the point where it feels like this fundamental part of the language is as easy to use and idiomatic as the standard library itself. At that point I’d be very much for dropping the prefixes.

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

Since it’s a basic API that most developers will be interacting with then yes, even though the change is fairly minor, it definitely bears consideration.

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

Yes and no. Prefixing types with NS definitely isn’t very Swift-y, but at the same time this is why I’d like to keep the current convention for existing (unchanged) types, as it makes it much clearer that these are things that weren’t originally designed for Swift and thus won’t behave quite as you might expect.

Completely agree

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

I’ve worked in languages where libraries had different styles of name-spacing, and while it was annoying to have a mixture, I think it was fine, especially for libraries that are older, as the prefix name-spacing style makes it absolutely clear that this is an older API.

Yes, we should be clear this is an older API, also to add motivation on introducing a more modern one (even if at first it just wraps Foundation with a more Swift-like API)

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

Quick read of the proposal, kept an eye on the discussion leading up to it though.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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