[Review] SE-0080: Failable Numeric Conversion Initializers


(Chris Lattner) #1

Hello Swift community,

The review of "SE-0080: Failable Numeric Conversion Initializers" begins now and runs through May 9. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.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


(Charles Srstka) #2

Is the proposal to add these initializers to protocols like IntegerType, or just to individually add them to each of the numeric types? It’s unclear from the proposal, but in case that question hasn’t been decided yet, I’d like to vote for putting them in the protocols. It’s bugged me for a while that IntegerType doesn’t contain any of the existing initializers, even though every single type that conforms to it contains them, and even though FloatingPointType also contains them. Having support for these initializers in the protocol lets you do things like initialize generalized integer types in generic functions, which can be handy sometimes.

Charles

···

On May 3, 2016, at 10:57 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0080: Failable Numeric Conversion Initializers" begins now and runs through May 9. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.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


#3

The review of "SE-0080: Failable Numeric Conversion Initializers" begins now and runs through May 9. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md

Hello,

I'm all for it, but I'd like a clarification about... the Integer / Floating point interface.

I once had to write a function that compares Int64 to Double for strict equality, with all the sweats that come whenever you deal with floating point representations and have to introduce two-complements representation of integers as a mandatory precondition:

  /// Returns true if i and d hold exactly the same value, and if converting one
  /// type into the other does not lose any information.
  private func int64EqualDouble1(_ i: Int64, _ d: Double) -> Bool {
      return (d >= Double(Int64.min))
          && (d < Double(Int64.max))
          && (round(d) == d)
          && (i == Int64(d))
  }

As I understand well the proposal, I could write instead:

  private func int64EqualDouble2(_ i: Int64, _ d: Double) -> Bool {
      guard let j = Int64(exact: d) else { return false }
      return i == j
  }

But I may be wrong!

The "without loss of information" in the proposal means that -0.0 (minus zero) would *not* be convertible to Int64 (which would lose the sign). And we'd get:

  int64EqualDouble1(0, -0.0) // true
  int64EqualDouble2(0, -0.0) // false

No problem with that. To know if int64EqualDouble1 has a bug, or if int64EqualDouble2 should handle -0.0 explicitly, one needs to know how -0.0 should be handled.

So I think that the proposal should make it very clear how it wants to handle all the funny Float and Double values. Without such a clarification, as handy as they look like, those functions would remain surprising, which means very hard to use well, and we'll keep on sweating.

Gwendal Roué


(Stephen Canon) #4

First, a general +1 to these, thanks for proposing them.

In SE-0067 we spelled these “exactly” rather than “exact”.
init?<Source: Integer>(exactly value: Source)

As for –0, Int(exactly: -0.0) should *not* fail. My rationale for this is as follows:

- While information (the signbit) is lost, the essential property is that `Double(Int(exactly: -0.0)) == -0.0`.
- If we instead adopted “no information loss” as a criteria, we would back ourselves into a corner w.r.t decimal floating-point types, which have multiple representations of most values (1.0 can be encoded as 1e0 or 10e-1 or 100e-2 …). The result would be that these initializers would always fail for decimal fp inputs.

– Steve


(Colin Barrett) #5

Swift numeric types all currently have a family of conversion initializers. In many use cases they leave a lot to be desired. Initializing an integer type with a floating point value will truncate any fractional portion of the number. Initializing with an out-of-range value traps.

Have you considered whether it makes sense to keep these around? Maybe the failable ones should be the default, and give the other ones a more descriptive 1st argument label.

-Colin


(Max Moiseev) #6

Hi all,

This email is the result of a discussion between members of the standard library team.

We suggest changing the initializers argument label to `exactly` to match the one used in the floating point protocols proposal <https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md>. Other than that the proposal seems to be a valuable addition to the standard library.

max

···

On May 3, 2016, at 8:57 PM, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of "SE-0080: Failable Numeric Conversion Initializers" begins now and runs through May 9. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.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


(Chris Lattner) #7

Is the proposal to add these initializers to protocols like IntegerType, or just to individually add them to each of the numeric types? It’s unclear from the proposal, but in case that question hasn’t been decided yet, I’d like to vote for putting them in the protocols. It’s bugged me for a while that IntegerType doesn’t contain any of the existing initializers, even though every single type that conforms to it contains them, and even though FloatingPointType also contains them. Having support for these initializers in the protocol lets you do things like initialize generalized integer types in generic functions, which can be handy sometimes.

The tentative plan is for the integer protocols to get revised in Swift 3 to be more similar to the recently approved floating point protocols. If SE-0080 gets accepted, it stands to reason that that revision should take these initializers into account. Just MHO, but I don’t think there is any point in worrying about the currently known suboptimal integer protocol we have from Swift 2.

-Chris

···

On May 3, 2016, at 9:19 PM, Charles Srstka <cocoadev@charlessoft.com> wrote:

Charles

On May 3, 2016, at 10:57 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0080: Failable Numeric Conversion Initializers" begins now and runs through May 9. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.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


(Matthew Johnson) #8

Is the proposal to add these initializers to protocols like IntegerType, or just to individually add them to each of the numeric types? It’s unclear from the proposal, but in case that question hasn’t been decided yet, I’d like to vote for putting them in the protocols. It’s bugged me for a while that IntegerType doesn’t contain any of the existing initializers, even though every single type that conforms to it contains them, and even though FloatingPointType also contains them. Having support for these initializers in the protocol lets you do things like initialize generalized integer types in generic functions, which can be handy sometimes.

This proposal was written quite a while ago. It does not discuss the numeric protocols partly because I knew they were going to be revised and partly because I wanted to keep the proposal as lean as possible.

I agree that having support for these initializers included in the standard numeric protocols would be great. The best path, since review has started, is probably to accept this proposal as-is. Adding the implementations to the types themselves is necessary if the types are going to conform to a protocol that includes these initializers. The upcoming Integer protocol proposal could incorporate them if desired, along with a tweak to include them in the new FloatingPoint protocol as well. On the other hand, I would be happy to update the proposal, but could only reference the new FloatingPoint protocol, not the upcoming Integer protocol.

···

On May 3, 2016, at 11:19 PM, Charles Srstka via swift-evolution <swift-evolution@swift.org> wrote:

Charles

On May 3, 2016, at 10:57 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0080: Failable Numeric Conversion Initializers" begins now and runs through May 9. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md

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

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

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

What goes into a review?

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

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

More information about the Swift evolution process is available at

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

Thank you,

-Chris Lattner
Review Manager

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

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


(Matthew Johnson) #9

The review of "SE-0080: Failable Numeric Conversion Initializers" begins now and runs through May 9. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md

Hello,

I'm all for it, but I'd like a clarification about... the Integer / Floating point interface.

I once had to write a function that compares Int64 to Double for strict equality, with all the sweats that come whenever you deal with floating point representations and have to introduce two-complements representation of integers as a mandatory precondition:

  /// Returns true if i and d hold exactly the same value, and if converting one
  /// type into the other does not lose any information.
  private func int64EqualDouble1(_ i: Int64, _ d: Double) -> Bool {
      return (d >= Double(Int64.min))
          && (d < Double(Int64.max))
          && (round(d) == d)
          && (i == Int64(d))
  }

As I understand well the proposal, I could write instead:

  private func int64EqualDouble2(_ i: Int64, _ d: Double) -> Bool {
      guard let j = Int64(exact: d) else { return false }
      return i == j
  }

But I may be wrong!

The "without loss of information" in the proposal means that -0.0 (minus zero) would *not* be convertible to Int64 (which would lose the sign). And we'd get:

  int64EqualDouble1(0, -0.0) // true
  int64EqualDouble2(0, -0.0) // false

No problem with that. To know if int64EqualDouble1 has a bug, or if int64EqualDouble2 should handle -0.0 explicitly, one needs to know how -0.0 should be handled.

This is a good example to consider. I am not a numerics expert and hadn’t thought to consider -0.0. Intuitively I would expect that to convert to 0 when converted to an integer type, however your are right that this is technically a loss of information about the sign bit.

I am happy to defer to those with more numerics expertise than I have about what an implementation should do in this case. I am also happy to defer to numerics experts about how to precisely define “loss of information” in general.

As noted in the proposal, the primary use case I am concerned with is reading data from semi-structured sources such as JSON where there is only a single “number” type. In these cases the value will be received as a Double but our model may specify an Int, Uint, Int8, etc. Any implementation that allows for validating the conformance of a value to expectations of our model and extracting the valid value with the correct type will be sufficient for the use cases I can imagine.

So I think that the proposal should make it very clear how it wants to handle all the funny Float and Double values. Without such a clarification, as handy as they look like, those functions would remain surprising, which means very hard to use well, and we'll keep on sweating.

Are there any values other than -0.0 we need to worry about? Clearly NaN, Infinity, and -Infinity cannot be represented by integer types and integer initializers would return nil when called with these floating point values.

···

On May 3, 2016, at 11:26 PM, Gwendal Roué via swift-evolution <swift-evolution@swift.org> wrote:

Gwendal Roué

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


(Matthew Johnson) #10

Swift numeric types all currently have a family of conversion initializers. In many use cases they leave a lot to be desired. Initializing an integer type with a floating point value will truncate any fractional portion of the number. Initializing with an out-of-range value traps.

Have you considered whether it makes sense to keep these around? Maybe the failable ones should be the default, and give the other ones a more descriptive 1st argument label.

That’s a good question. It might be a good idea, but I wanted to keep this proposal small and non-breaking to maximize chances of acceptance. I would support that change to the proposal if the core team was interested in going that direction.

···

On May 4, 2016, at 6:56 PM, Colin Barrett via swift-evolution <swift-evolution@swift.org> wrote:

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


(Colin Barrett) #11

Thanks Matthew. Personally I would really like to see an analysis of the tradeoffs therein covered in the proposal in some way.

-Colin (via thumbs)

···

On May 4, 2016, at 8:23 PM, Matthew Johnson <matthew@anandabits.com> wrote:

On May 4, 2016, at 6:56 PM, Colin Barrett via swift-evolution <swift-evolution@swift.org> wrote:

Swift numeric types all currently have a family of conversion initializers. In many use cases they leave a lot to be desired. Initializing an integer type with a floating point value will truncate any fractional portion of the number. Initializing with an out-of-range value traps.

Have you considered whether it makes sense to keep these around? Maybe the failable ones should be the default, and give the other ones a more descriptive 1st argument label.

That’s a good question. It might be a good idea, but I wanted to keep this proposal small and non-breaking to maximize chances of acceptance. I would support that change to the proposal if the core team was interested in going that direction.

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


(Matthew Johnson) #12

Hi all,

This email is the result of a discussion between members of the standard library team.

We suggest changing the initializers argument label to `exactly` to match the one used in the floating point protocols proposal. Other than that the proposal seems to be a valuable addition to the standard library.

Thanks Max. I'm glad to hear that! Should I update the proposal or will you just make that change as part of "accepted with modification"?

···

Sent from my iPhone

On May 5, 2016, at 5:19 PM, Max Moiseev via swift-evolution <swift-evolution@swift.org> wrote:

max

On May 3, 2016, at 8:57 PM, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of "SE-0080: Failable Numeric Conversion Initializers" begins now and runs through May 9. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.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


(Dave Abrahams) #13

That would overturn Swift's fundamental programming model for numerics,
which is based on the fact that, to a first approximation, everybody
codes, **and wants to continue coding** as though their Int is really an
unbounded integer and their Double is an unbounded real number with
unlimited precision. We very intentionally make the limitations of our
numeric types observable, but also not in-your-face for basic operations.

If we were to go this route, we would also make you unwrap the result of
x + 1 because it might overflow.

···

on Wed May 04 2016, Colin Barrett <swift-evolution@swift.org> wrote:

Swift numeric types all currently have a family of conversion

initializers. In many use cases they leave a lot to be
desired. Initializing an integer type with a floating point value will
truncate any fractional portion of the number. Initializing with an
out-of-range value traps.

Have you considered whether it makes sense to keep these around? Maybe
the failable ones should be the default, and give the other ones a
more descriptive 1st argument label.

--
Dave


(Max Moiseev) #14

Hi Matthew,

In general, if you think there is something to be updated in the proposal, it is worth creating a new revision (like in the floating point protocols proposal, for example) and mentioning it in the thread.

I think it is a way to go in this particular case, since we are still in the first half of the review period. Any further discussion would benefit from it.

max

···

On May 5, 2016, at 4:02 PM, Matthew Johnson <matthew@anandabits.com> wrote:

Sent from my iPhone

On May 5, 2016, at 5:19 PM, Max Moiseev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

This email is the result of a discussion between members of the standard library team.

We suggest changing the initializers argument label to `exactly` to match the one used in the floating point protocols proposal <https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md>. Other than that the proposal seems to be a valuable addition to the standard library.

Thanks Max. I'm glad to hear that! Should I update the proposal or will you just make that change as part of "accepted with modification"?

max

On May 3, 2016, at 8:57 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

Hello Swift community,

The review of "SE-0080: Failable Numeric Conversion Initializers" begins now and runs through May 9. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.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 <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


(Matthew Johnson) #15

Hi Matthew,

In general, if you think there is something to be updated in the proposal, it is worth creating a new revision (like in the floating point protocols proposal, for example) and mentioning it in the thread.

I think it is a way to go in this particular case, since we are still in the first half of the review period. Any further discussion would benefit from it.

t made the change and submitted a PR.

···

On May 5, 2016, at 6:22 PM, Max Moiseev <moiseev@apple.com> wrote:

max

On May 5, 2016, at 4:02 PM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:

Sent from my iPhone

On May 5, 2016, at 5:19 PM, Max Moiseev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

This email is the result of a discussion between members of the standard library team.

We suggest changing the initializers argument label to `exactly` to match the one used in the floating point protocols proposal <https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md>. Other than that the proposal seems to be a valuable addition to the standard library.

Thanks Max. I'm glad to hear that! Should I update the proposal or will you just make that change as part of "accepted with modification"?

max

On May 3, 2016, at 8:57 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

Hello Swift community,

The review of "SE-0080: Failable Numeric Conversion Initializers" begins now and runs through May 9. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.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 <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