[Review] SE-0098: Lowercase didSet and willSet for more consistent keyword casing


(Chris Lattner) #1

Hello Swift community,

The review of "SE-0098: Lowercase didSet and willSet for more consistent keyword casing" begins now and runs through May 30. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0098-didset-capitalization.md

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

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

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

What goes into a review?

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

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

More information about the Swift evolution process is available at

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

Thank you,

-Chris Lattner
Review Manager


(Joe Groff) #2

didSet and willSet are already contextual rather than formal keywords, and there's a conceivable future where didSet and willSet are no longer keywords at all if we run with the "property behaviors" feature again in the future. If we think that's likely, I'm not sure this intermediate churn is really worth it.

-Joe

···

On May 24, 2016, at 11:07 AM, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of "SE-0098: Lowercase didSet and willSet for more consistent keyword casing" begins now and runs through May 30. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0098-didset-capitalization.md

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

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

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

What goes into a review?

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

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

More information about the Swift evolution process is available at

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

Thank you,

-Chris Lattner
Review Manager

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


(Chéyo Jiménez) #3

Hello Swift community,

The review of "SE-0098: Lowercase didSet and willSet for more consistent keyword casing" begins now and runs through May 30. The proposal is available here:

   https://github.com/apple/swift-evolution/blob/master/proposals/0098-didset-capitalization.md

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

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

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

What goes into a review?

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

   * What is your evaluation of the proposal?

-1 bc it doesn't address the fact that property behaviors will have their own naming convention separate from keyboard naming in order to address 2+ word properly names; not to mention syntax changes that will be part of the name signature.

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

No

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

No

   * 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 study.

···

On May 24, 2016, at 11:07 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

More information about the Swift evolution process is available at

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

Thank you,

-Chris Lattner
Review Manager

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


(Ricardo Parada) #4

Hello Swift community,

The review of "SE-0098: Lowercase didSet and willSet for more consistent keyword casing" begins now and runs through May 30. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0098-didset-capitalization.md

  * What is your evaluation of the proposal?

-1.

I strongly believe that these should NOT be renamed to lowercase conjoined. I anticipate these will become accessors when property behaviors are implemented in the future. Accessors are defined by the implementor of the property behavior and they feel like calling a method or function. They should be subject to lowerCamelCase, just like instance methods and properties.

In addition, lowercase conjoined does not look that good when you start having more than two words conjoined. On the other hand lowerCameCase is richer and I find it easier to read.

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

This change is not necessary. I don’t at these as keywords specially knowing that accessors and property behaviors will be arriving in the future.

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

No. I think what’s wrong with this proposal is that is based on the assumption that willSet, didSet are keywords.

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

In java for example, in an object-to-relational mapping framework, there are method hooks such as willRead() that are methods that get called when accessing properties of the object and makes sure the data is fetched from the database. In this case, willRead() is just a method in the object. I look at the willSet and didSet as playing similar roles.

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

I’ve been following the discussions prior to the proposal and I’m now reading the responses to the proposal.

Thanks

···

On May 24, 2016, at 2:07 PM, Chris Lattner <clattner@apple.com> wrote:


(Lily Ballard) #5

  * What is your evaluation of the proposal?

-1. The only real rationale here is "other keywords that are compound words are all lowercase instead of camelCase" (except for dynamicType). But that's not a very compelling argument. More generally, I think `willSet` and `didSet` just looks better, and I think this may be because they are different types of phrases entirely than associatedtype, typealias, and fallthrough (they're certainly classified differently grammatically; willSet and didSet are verb pharses, associatedtype is an adjective phrase, typealias is a noun modifier [which is like an adjective phrase], and fallthrough is a compound word with precedent in other languages). They're also companions to the `set` declaration. Since `set` is a distinct concept in its own right, `willSet` and `didSet` highlight the fact that they're modifiers on the word `set`. In fact, if we had a distinct `type` declaration, then I think I'd want to change `associatedtype` into `associatedType`. The camel casing makes it more obvious that this is a variant on the root word, whereas all-lowercase implies that the entire conjoined phrase is a single standalone concept.

Also, as others have already pointed out, willSet and didSet will hopefully end up as property behaviors rather than language keywords, and in that case the stated rationale doesn't apply.

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

No. The rationale for this can largely be summed up as aesthetic preference and it's pretty subjective.

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

Does bikeshedding syntax count as fitting with the feel and direction of Swift? :wink:

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

I'm having trouble thinking of a relevant language that uses phrases for keywords. I believe all of the keywords in Rust are single words. Haskell actually uses phrases rather than conjoined keywords, e.g. `data instance`, `type family`, etc. Obj-C/C generally uses snake_case.

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

A quick reading of the proposal and a reading of the review thread to date.

-Kevin Ballard

···

On Tue, May 24, 2016, at 11:07 AM, Chris Lattner wrote:


(Michael Peternell) #6

(comments inline)

Hello Swift community,

The review of "SE-0098: Lowercase didSet and willSet for more consistent keyword casing" begins now and runs through May 30. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0098-didset-capitalization.md

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

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

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

What goes into a review?

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

  * What is your evaluation of the proposal?

-1 . I don't like this. I don't find the consistency arguments convincing. Consistency has to be defined in terms of observable behavior of the language; If a word is a "keyword" or not is an implementation detail of the compiler IMHO(!), so there should be no rule regarding case-ness of keywords.

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

No, I'd rather see progress on static/dynamic dispatch rules of protocol extensions, for example. Changing the case-ness of just two random language keywords doesn't have any influence on the ABI or the API or the semantics of the language.

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

Don't think so.

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

ObjC has -willSetValueForKey: and -didSetValueForKey: . It's not the same, because willSet and didSet are not related to KVO. But using the same camelCase syntax for didSet and willSet feels more consistent to me. At least, the semantic distance between didSet and -didSetValueForKey: is less than the semantic distance between didSet and associatedtype. (I compare them because associatedtype is also a keyword, and it's all lowercase.)

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

Read the proposal, participated in the discussion.

-Michael

···

Am 24.05.2016 um 20:07 schrieb Chris Lattner via swift-evolution <swift-evolution@swift.org>:


(Brent Royal-Gordon) #7

  * What is your evaluation of the proposal?

If we are absolutely, 100% sure that we are going to use lowercase naming for other accessors, including user-defined ones for property behaviors, then I see no reason not to do this now. If we are less than, say, 95% sure, I don't think we should do this yet. Changing from `willSet` to `willset` in Swift 3.2 or Swift 4 has a much smaller cost than changing to `willset` in Swift 3 and then back to `willSet` in a future version; jerking users around like that is likely to upset them.

And I don't think we should be 95% sure that all future accessors will be all-lowercase, because I think making them all-lowercase would be a *very* dubious decision, for several reasons:

1) `willset` and `didset` are less readable than `willSet` and `didSet`.

2) It is likely that many user-defined accessors will be impacted even more severely by all-lowercasing than `willset` and `didset`. Try to parse out names like `willlock` or `xmlid` or `enqueueforreading`, compared to the mixed-case `willLock`, `xmlID`, and `enqueueForReading`, and you'll see what I mean.

3) User-defined accessors will not only be defined; they will also be called. And these calls will look very strange indeed, given their keyword-like capitalization.

4) Keywords are all-lowercase because they are so familiar, and so intrinsic to the language's grammar, that an experienced Swift developer does not really read them so much as recognize them. But `willSet` and `didSet` *do* need to be read, because they are very similar keywords (one-character length difference) which both appear in the same context. And user-defined accessors will need to be read even more, because their names will be arbitrary and quite possibly used infrequently. The requirements of an accessor name are simply different from a declaration like `associatedtype`.

5) Keywords are *also* all-lowercase because they are rare multi-word examples of a class of names which are typically short and single-word. For instance, `associatedtype` and `typealias` belong to a class of declaration keywords which include `let`, `var`, `func`, `subscript`, `init`, `deinit`, `class`, `struct`, `enum`, `protocol`, and `extension`, all single-word keywords. `fallthrough` belongs to the same class as `break`, `continue`, `return`, `throw`, and `try`, as well as arguably `if`, `else`, `guard`, `switch`, `case`, `where`, `while`, `repeat`, `for`, `do`, and `catch`, again all single-word keywords. By contrast, I doubt that very many accessors will be single-word; currently we have two single-word ones and two multi-word ones, and most examples of user-defined accessors I've seen have been multi-word.

Because I think we should probably not adopt all-lowercase user-defined accessor names, and because I think it is *much* better to make this change later than to make it now and undo it later, I think we probably should defer this proposal until the property behavior design has solidified.

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

Yes, but *only* if we are certain that this is the direction we want accessors to take—and I don't think we should be that certain.

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

Maybe. It depends on the design of future features.

  * 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?

Participated in previous discussions.

···

--
Brent Royal-Gordon
Architechies


(Patrick Smith) #8

I agree with Joe, so -1 from me.

There’s no hurry to pin down rules for a feature which hasn’t been fully developed. Staying with the existing naming will reduce confusion. And I think camelCase will be the best fit for property behaviours, so this is an unnecessary move.

···

On 25 May 2016, at 4:07 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0098: Lowercase didSet and willSet for more consistent keyword casing" begins now and runs through May 30. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0098-didset-capitalization.md

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

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

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

What goes into a review?

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

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

More information about the Swift evolution process is available at

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

Thank you,

-Chris Lattner
Review Manager

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


(David Owens II) #9

+1.

If Swift is going to state that keywords need to be lowercased, conjoined words, then there should be no exceptions to that rule without some fairly significant gain.

It’s also a fairly low-impact change for any fixit to be run.

-David

···

On May 24, 2016, at 11:21 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

didSet and willSet are already contextual rather than formal keywords, and there's a conceivable future where didSet and willSet are no longer keywords at all if we run with the "property behaviors" feature again in the future. If we think that's likely, I'm not sure this intermediate churn is really worth it.

-Joe

On May 24, 2016, at 11:07 AM, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of "SE-0098: Lowercase didSet and willSet for more consistent keyword casing" begins now and runs through May 30. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0098-didset-capitalization.md

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

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

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

What goes into a review?

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

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

More information about the Swift evolution process is available at

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

Thank you,

-Chris Lattner
Review Manager

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

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


(John McCall) #10

didSet and willSet are already contextual rather than formal keywords, and there's a conceivable future where didSet and willSet are no longer keywords at all if we run with the "property behaviors" feature again in the future. If we think that's likely, I'm not sure this intermediate churn is really worth it.

I agree.

The general principle here is that the language should always promote consistent conventions in the "same place". So e.g. if we wanted to add intrinsic operations to the language that are spelled exactly like function calls — imagine "dynamicType(x)" if that couldn't just be a library function — then we would use camelCase for those keywords because they fill the same space as a user-defined function call. If we somehow find a way to allow user-provided declaration introducers, we would expect those to be lowercased for consistency with the language-provided ones. And so on.

Since it's reasonable to anticipate that we will someday allow user-defined storage behaviors, and we expect it to be most sensible to name those accessors using camelCase conventions, we should use those conventions even for things that are currently built-in to the language.

This also avoids creating weird situations in five years where certain things are spelled inconsistently because they used to be builtins and no longer are (which may even apply to willSet / didSet).

John.

···

On May 24, 2016, at 11:21 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

-Joe

On May 24, 2016, at 11:07 AM, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of "SE-0098: Lowercase didSet and willSet for more consistent keyword casing" begins now and runs through May 30. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0098-didset-capitalization.md

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

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

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

What goes into a review?

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

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

More information about the Swift evolution process is available at

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

Thank you,

-Chris Lattner
Review Manager

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

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


(Matthew Johnson) #11

didSet and willSet are already contextual rather than formal keywords, and there's a conceivable future where didSet and willSet are no longer keywords at all if we run with the "property behaviors" feature again in the future. If we think that's likely, I'm not sure this intermediate churn is really worth it.

+1. If we may introduce property behaviors (I hope we do) the naming of 'didSet' and 'willSet' should match the convention for accessors. As those are user-defined and it is not unreasonable to imaging accessorswithseveralwords in their name, I believe e appropriate convention would be lower camel case. As this is the status quo, I believe it is preliminary to make a change.

If a time comes where we either decide against property behaviors and that these should match the all lowercase convention of keywords, or decide to introduce property behaviors with a convention that accessors should be all lowercase migration could easily provided.

···

Sent from my iPad

On May 24, 2016, at 1:21 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

-Joe

On May 24, 2016, at 11:07 AM, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of "SE-0098: Lowercase didSet and willSet for more consistent keyword casing" begins now and runs through May 30. The proposal is available here:

   https://github.com/apple/swift-evolution/blob/master/proposals/0098-didset-capitalization.md

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

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

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

What goes into a review?

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

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

More information about the Swift evolution process is available at

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

Thank you,

-Chris Lattner
Review Manager

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

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


(Tino) #12

-1

I'm not sure this intermediate churn is really worth it.

That has been my opinion in the original thread, and I haven't read anything that changed my mind:
Better live with a tiny inconsistency now than deal with three different forms of didSet/willSet in the future.


(Thorsten Seitz) #13

I totally agree with the arguments brought forth by John and Joe.

Therefore -1 to the proposal

-Thorsten

···

Am 24.05.2016 um 20:39 schrieb John McCall via swift-evolution <swift-evolution@swift.org>:

On May 24, 2016, at 11:21 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
didSet and willSet are already contextual rather than formal keywords, and there's a conceivable future where didSet and willSet are no longer keywords at all if we run with the "property behaviors" feature again in the future. If we think that's likely, I'm not sure this intermediate churn is really worth it.

I agree.

The general principle here is that the language should always promote consistent conventions in the "same place". So e.g. if we wanted to add intrinsic operations to the language that are spelled exactly like function calls — imagine "dynamicType(x)" if that couldn't just be a library function — then we would use camelCase for those keywords because they fill the same space as a user-defined function call. If we somehow find a way to allow user-provided declaration introducers, we would expect those to be lowercased for consistency with the language-provided ones. And so on.

Since it's reasonable to anticipate that we will someday allow user-defined storage behaviors, and we expect it to be most sensible to name those accessors using camelCase conventions, we should use those conventions even for things that are currently built-in to the language.

This also avoids creating weird situations in five years where certain things are spelled inconsistently because they used to be builtins and no longer are (which may even apply to willSet / didSet).

John.

-Joe

On May 24, 2016, at 11:07 AM, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of "SE-0098: Lowercase didSet and willSet for more consistent keyword casing" begins now and runs through May 30. The proposal is available here:

   https://github.com/apple/swift-evolution/blob/master/proposals/0098-didset-capitalization.md

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

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

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

What goes into a review?

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

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

More information about the Swift evolution process is available at

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

Thank you,

-Chris Lattner
Review Manager

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

_______________________________________________
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