[Gardening] Migrate lists.swift.org links to forums.swift.org (#1266)

This commit changes all 536 remaining lists.swift.org links to their corresponding forums.swift.org URLs.

- `0012-add-noescape-to-public-library-api.md` – I changed this link because it pointed to a only marginally related discussion, not the actual pitch for SE-0012:
  > [Swift Evolution Discussion Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/009270.html)

- In some instances it was possible to simplify the links because the forums combines the weekly mailing list archives into a single thread.
  Examples:
  - `0033-import-objc-constants.md` – these two links can be combined into one:
    > Swift-evolution thread: [Original E-Mail](https://forums.swift.org/t/pitch-import-objective-c-constants-as-enums/1114), [Replies](https://forums.swift.org/t/pitch-import-objective-c-constants-as-enums)
  - `0085-package-manager-command-name.md` – these two links became the same thread in Discourse:
    > [Swift Build Review Thread](https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160509/000438.html)
    >
    > [Swift Evolution Review Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/016931.html)

- I changed some links to point to the top of the respective pitch/review thread, not some post in the middle. Presumably, this was done previously to capture the majority of the discussion in Mailman’s week-based archives, but Discourse has thankfully combined the weekly threads. (I only did this for links that obviously pointed to entire pitch/review discussions, not links that specifically link to a point to highlight a point made in that post.)

  List of these changes:
  - `0045-scan-takewhile-dropwhile`:
    > Swift-evolution thread:
    > [Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011923.html)
  - `0070-optional-requirements.md`:
    > * [Is there an underlying reason why optional protocol requirements need @objc?](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011854.html)
  - `0078-rotate-algorithm.md`:
    > [Swift-evolution thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002213.html)
  - `0079-upgrade-self-from-weak-to-strong.md`:
    > - [Allowing `guard let self = self else { … }` for weakly captured self in a closure.](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/009023.html)
  - `0180-string-index-overhaul.md`:
    > Swift-evolution thread: [Pitch: String Index Overhaul](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170529/036874.html)
  - `0189-restrict-cross-module-struct-initializers.md`:
    > * [Swift Evolution Review Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171120/041478.html)
  - `0190-target-environment-platform-condition.md`:
    > * [Swift Evolution Review Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171127/041695.html)

- Deleted commented-out vestiges from the proposal template, both to clean up and to remove the last vestiges of lists.swift.org links, like this one:

  > ```
  > <!--
  > *During the review process, add the following fields as needed:*
  >
  > * Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/), [Additional Commentary](https://lists.swift.org/pipermail/swift-evolution/)
  > * Bugs: [SR-NNNN](https://bugs.swift.org/browse/SR-NNNN), [SR-MMMM](https://bugs.swift.org/browse/SR-MMMM)
  > * Previous Revision: [1](https://github.com/apple/swift-evolution/blob/...commit-ID.../proposals/NNNN-filename.md)
  > * Previous Proposal: [SE-XXXX](XXXX-filename.md)
  > -->
  > ```

  File list:
  - `0153-compensate-for-the-inconsistency-of-nscopyings-behaviour`
  - `0189-restrict-cross-module-struct-initializers.md`
  - `0192-non-exhaustive-enums.md`
  - `0198-playground-quicklook-api-revamp.md`

Author: ole

Diff for: commonly_proposed.md

@@ -4,7 +4,7 @@
 * Author: [David Farler](https://github.com/bitjammer)
 * Review Manager: [Joe Pamer](https://github.com/jopamer)
 * Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/008145.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/se-0003-removing-var-from-function-parameters-and-pattern-matching/1230)
 * Implementation: [apple/swift@8a5ed40](https://github.com/apple/swift/commit/8a5ed405bf1f92ec3fc97fa46e52528d2e8d67d9)
 
 ## Note
@@ -104,9 +104,9 @@ burden it placed on valid mutation patterns already in use in Swift 2
 code. You can view the discussion on the swift-evolution mailing list
 here:
 
-[Initial Discussion of Reconsideration](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007326.html)
+[Initial Discussion of Reconsideration](https://forums.swift.org/t/reconsidering-se-0003-removing-var-from-function-parameters-and-pattern-matching/1159)
 
 The rationale for a final conclusion was also sent to the
 swift-evolution list, which you can view here:
 
-[Note on Revision of the Proposal](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/008145.html)
+[Note on Revision of the Proposal](https://forums.swift.org/t/se-0003-removing-var-from-function-parameters-and-pattern-matching/1230)

Diff for: proposals/0003-remove-var-parameters.md

@@ -4,19 +4,19 @@
 * Authors: [Doug Gregor](https://github.com/DougGregor), [Dave Abrahams](https://github.com/dabrahams)
 * Review Manager: [Doug Gregor](https://github.com/DougGregor)
 * Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011770.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-with-modification-se-0005-better-translation-of-objective-c-apis-into-swift/1668)
 
 ## Reviewer notes
 
 This review is part of a group of three related reviews, running
 concurrently:
 
 * [SE-0023 API Design Guidelines](0023-api-guidelines.md)
-  ([Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007353.html))
+  ([Review](https://forums.swift.org/t/review-se-0023-api-design-guidelines/1162))
 * [SE-0006 Apply API Guidelines to the Standard Library](0006-apply-api-guidelines-to-the-standard-library.md)
-  ([Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007354.html))
+  ([Review](https://forums.swift.org/t/review-se-0006-apply-api-guidelines-to-the-standard-library/1163))
 * [SE-0005 Better Translation of Objective-C APIs Into Swift](0005-objective-c-name-translation.md)
-  ([Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007355.html))
+  ([Review](https://forums.swift.org/t/review-se-0005-better-translation-of-objective-c-apis-into-swift/1164))
 
 These reviews are running concurrently because they interact strongly
 (e.g., an API change in the standard library will correspond to a

Diff for: proposals/0005-objective-c-name-translation.md

@@ -4,19 +4,19 @@
 * Authors: [Dave Abrahams](https://github.com/dabrahams), [Dmitri Gribenko](https://github.com/gribozavr), [Maxim Moiseev](https://github.com/moiseev)
 * Review Manager: [Doug Gregor](https://github.com/DougGregor)
 * Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000054.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-with-modifications-se-0006-apply-api-guidelines-to-the-standard-library/1667)
 
 ## Reviewer notes
 
 This review is part of a group of three related reviews, running
 concurrently:
 
 * [SE-0023 API Design Guidelines](0023-api-guidelines.md)
-  ([Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007353.html))
+  ([Review](https://forums.swift.org/t/review-se-0023-api-design-guidelines/1162))
 * [SE-0006 Apply API Guidelines to the Standard Library](0006-apply-api-guidelines-to-the-standard-library.md)
-  ([Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007354.html))
+  ([Review](https://forums.swift.org/t/review-se-0006-apply-api-guidelines-to-the-standard-library/1163))
 * [SE-0005 Better Translation of Objective-C APIs Into Swift](0005-objective-c-name-translation.md)
-  ([Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007355.html))
+  ([Review](https://forums.swift.org/t/review-se-0005-better-translation-of-objective-c-apis-into-swift/1164))
 
 These reviews are running concurrently because they interact strongly
 (e.g., an API change in the standard library will correspond to a

Diff for: proposals/0006-apply-api-guidelines-to-the-standard-library.md

@@ -4,7 +4,7 @@
 * Author: [Erica Sadun](https://github.com/erica)
 * Review Manager: [Doug Gregor](https://github.com/DougGregor)
 * Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2015-December/000001.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0007-remove-c-style-for-loops-with-conditions-and-incrementers/512)
 * Bugs: [SR-226](https://bugs.swift.org/browse/SR-226), [SR-227](https://bugs.swift.org/browse/SR-227)
 
 ## Introduction
@@ -19,7 +19,7 @@ language.
 
 The value of this construct is limited and I believe its removal should be seriously considered.
 
-This proposal was discussed on the Swift Evolution list in the [C-style For Loops](https://lists.swift.org/pipermail/swift-evolution/2015-December/000053.html) thread and reviewed in the [\[Review\] Remove C-style for-loops with conditions	and incrementers](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000913.html) thread.
+This proposal was discussed on the Swift Evolution list in the [C-style For Loops](https://forums.swift.org/t/c-style-for-loops/31) thread and reviewed in the [\[Review\] Remove C-style for-loops with conditions	and incrementers](https://forums.swift.org/t/review-remove-c-style-for-loops-with-conditions-and-incrementers/255) thread.
 
 ## Advantages of For Loops
 

Diff for: proposals/0007-remove-c-style-for-loops.md

@@ -4,7 +4,7 @@
 * Author: [Oisin Kidney](https://github.com/oisdk)
 * Review Manager: [Doug Gregor](https://github.com/DougGregor)
 * Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004418.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0008-add-a-lazy-flatmap-for-sequences-of-optionals/748)
 * Bug: [SR-361](https://bugs.swift.org/browse/SR-361)
 
 ## Introduction ##
@@ -39,7 +39,7 @@ However, there is only a lazy implementation for the first version:
 // [1, 2, 3, 4, 5]
 ```
 
-Swift Evolution Discussions: [Lazy flatMap for Optionals](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151130/000534.html), [Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002592.html)
+Swift Evolution Discussions: [Lazy flatMap for Optionals](https://forums.swift.org/t/lazy-flatmap-for-optionals/127/3), [Review](https://forums.swift.org/t/review-add-a-lazy-flatmap-for-sequences-of-optionals/548)
 
 ## Motivation ##
 

Diff for: proposals/0008-lazy-flatmap-for-optionals.md

@@ -4,13 +4,13 @@
 * Author: [David Hart](https://github.com/hartbit)
 * Review Manager: [Doug Gregor](https://github.com/DougGregor)
 * Status: **Rejected**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005478.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/rejected-se-0009-require-self-for-accessing-instance-members/930)
 
 ## Introduction
 
 The current version of Swift (2.1) requires using `self` when accessing instance members in closures. The proposal suggests extending this to all member accesses (as is intrinsically the case in Objective-C). It has the benefit of documenting instance properties vs local variables and instance functions vs local functions or closures.
 
-[Swift Evolution Discussion Thread](https://lists.swift.org/pipermail/swift-evolution/2015-December/000209.html)
+[Swift Evolution Discussion Thread](https://forums.swift.org/t/proposal-re-instate-mandatory-self-for-accessing-instance-properties-and-functions/125)
 
 ## Motivation
 
@@ -21,7 +21,7 @@ This proposal makes it obvious which are instance properties vs local variables,
 * Less confusing from a learning point of view.
 * Lets the compiler warn users (and avoids bugs) where the authors mean to use a local variable but instead are unknowingly using an instance property (and the other way round).
 
-One example of a bug avoidable by the proposal ([provided by Rudolf Adamkovic](https://lists.swift.org/pipermail/swift-evolution/2015-December/000243.html)):
+One example of a bug avoidable by the proposal ([provided by Rudolf Adamkovic](https://forums.swift.org/t/proposal-re-instate-mandatory-self-for-accessing-instance-properties-and-functions/125/4)):
 
 ```swift
 class MyViewController : UIViewController {

Diff for: proposals/0009-require-self-for-accessing-instance-members.md

@@ -4,14 +4,14 @@
 * Author: [Lily Ballard](https://github.com/lilyball)
 * Review Manager: [Doug Gregor](https://github.com/DougGregor)
 * Status: **Rejected**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000045.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/rejected-se-0010-add-staticstring-unicodescalarview/1530)
 
 ## Introduction
 
 There is no way to create a substring of a `StaticString` that is still typed
 as `StaticString`. There should be.
 
-[Swift Evolution Discussion Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151130/000535.html), [Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005609.html)
+[Swift Evolution Discussion Thread](https://forums.swift.org/t/proposal-add-staticstring-unicodescalarview/199), [Review](https://forums.swift.org/t/review-se-0010-add-staticstring-unicodescalarview/942)
 
 ## Motivation
 

Diff for: proposals/0010-add-staticstring-unicodescalarview.md

@@ -4,7 +4,7 @@
 * Author: [Loïc Lecrenier](https://github.com/loiclec)
 * Review Manager: [Doug Gregor](https://github.com/DougGregor)
 * Status: **Implemented (Swift 2.2)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-January/000014.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0011-replace-typealias-keyword-with-associatedtype-for-associated-type-declarations/990)
 * Bug: [SR-511](https://bugs.swift.org/browse/SR-511)
 
 
@@ -21,7 +21,7 @@ confusion surrounding the use of associated types.
 
 The proposed new keyword is `associatedtype`.
 
-[Review Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/005123.html)
+[Review Thread](https://forums.swift.org/t/review-replace-typealias-keyword-with-associatedtype-for-associated-type-declarations/880)
 
 ## Motivation
 
@@ -105,5 +105,5 @@ could be easily automated without any risk of breaking existing code.
 
 ## Mailing List
 
-- [Original](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151130/000470.html)
-- [Alternative Keywords](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003551.html)
+- [Original](https://forums.swift.org/t/introduce-associated-type-keyword/201)
+- [Alternative Keywords](https://forums.swift.org/t/se-0011-re-considering-the-replacement-keyword-for-typealias/669)

Diff for: proposals/0011-replace-typealias-associated.md

@@ -4,7 +4,7 @@
 * Author: [Jacob Bandes-Storch](https://github.com/jtbandes)
 * Review Manager: [Philippe Hausler](https://github.com/phausler)
 * Status: **Rejected**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019902.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/rejected-se-0097-normalizing-naming-for-negative-attributes/2854/9)
 
 ##### Revision history
 
@@ -18,7 +18,7 @@
 *  We propose exposing this attribute in CF and Foundation as `CF_NOESCAPE` and `NS_NOESCAPE`
 *  We also propose applying this declaration to a number of closure-taking APIs in CF and Foundation 
 
-[Swift Evolution Discussion Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/009270.html)
+[Swift Evolution Discussion Thread: \[Pitch\] make @noescape the default](https://forums.swift.org/t/pitch-make-noescape-the-default/664)
 
 ## Introduction
 

Diff for: proposals/0012-add-noescape-to-public-library-api.md

@@ -4,7 +4,7 @@
 * Author: [David Farler](https://github.com/bitjammer)
 * Review Manager: [Doug Gregor](https://github.com/DougGregor)
 * Status: **Rejected**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007316.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/rejected-se-0013-remove-partial-application-of-non-final-super-methods/1157)
 
 
 ## Introduction
@@ -24,7 +24,7 @@ those mechanisms, I propose that we disallow partial application of
 non-final methods through `super`, except where the `self` parameter is
 implicitly captured.
 
-[Swift Evolution Discussion Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000947.html)
+[Swift Evolution Discussion Thread](https://forums.swift.org/t/swift-2-2-removing-partial-application-of-super-method-calls/264)
 
 ## Motivation
 

Diff for: proposals/0013-remove-partial-application-super.md

@@ -4,7 +4,7 @@
 * Author: [Max Moiseev](https://github.com/moiseev)
 * Review Manager: [Doug Gregor](https://github.com/DougGregor)
 * Status: **Implemented (Swift 2.2)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-January/000008.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0014-constraining-anysequence-init/924)
 * Bug: [SR-474](https://bugs.swift.org/browse/SR-474)
 
 
@@ -13,7 +13,7 @@
 In order to allow `AnySequence` delegate calls to the underlying sequence,
 its initializer should have extra constraints.
 
-[Swift Evolution Discussion](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000910.html)
+[Swift Evolution Discussion](https://forums.swift.org/t/restricting-anysequence-init/254)
 
 ## Motivation
 

Diff for: proposals/0014-constrained-AnySequence.md

@@ -4,14 +4,14 @@
 * Author: [Lily Ballard](https://github.com/lilyball)
 * Review Manager: [Dave Abrahams](https://github.com/dabrahams)
 * Status: **Implemented (Swift 2.2)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004423.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/review-add-a-lazy-flatmap-for-sequences-of-optionals/695/4)
 * Implementation: [apple/swift#408](https://github.com/apple/swift/pull/408)
 
 ## Introduction
 
 Implement comparison operators on tuples up to some arity.
 
-[Swift Evolution Discussion](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000892.html), [Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/003907.html)
+[Swift Evolution Discussion](https://forums.swift.org/t/proposal-implement-and-for-tuples-where-possible-up-to-some-high-arity/251), [Review](https://forums.swift.org/t/review-add-a-lazy-flatmap-for-sequences-of-optionals/695)
 
 Note: The review was initially started on the wrong thread with the wrong title and subsequently corrected.
 

Diff for: proposals/0015-tuple-comparison-operators.md

@@ -4,7 +4,7 @@
 * Author: [Michael Buckley](https://github.com/MichaelBuckley)
 * Review Manager: [Chris Lattner](https://github.com/lattner)
 * Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000083.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0016-adding-initializers-to-int-and-uint-to-convert-from-unsafepointer-and-unsafemutablepointer/2005)
 * Bug: [SR-1115](https://bugs.swift.org/browse/SR-1115)
 * Previous Revision: [1](https://github.com/apple/swift-evolution/blob/ae2d7c24fff7cbdff754d9a4339e4fb02df5c690/proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md)
 
@@ -16,7 +16,7 @@ allow users to call C functions with `intptr_t` and `uintptr_t` parameters, and
 allow users to perform more advanced pointer arithmetic than is allowed by
 `UnsafePointer`s.
 
-[Swift Evolution Discussion](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001213.html), [Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013119.html)
+[Swift Evolution Discussion](https://forums.swift.org/t/proposal-add-initializers-for-converting-unsafepointers-to-int-and-unit/331), [Review](https://forums.swift.org/t/review-se-0016-adding-initializers-to-int-and-uint-to-convert-from-unsafepointer-and-unsafemutablepointer/1899)
 
 ## Motivation
 

Diff for: proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md

@@ -4,14 +4,14 @@
 * Author: [Jacob Bandes-Storch](https://github.com/jtbandes)
 * Review Manager: [Chris Lattner](https://github.com/lattner)
 * Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000133.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0017-change-unmanaged-to-use-unsafepointer/2461)
 * Bug: [SR-1485](https://bugs.swift.org/browse/SR-1485)
 
 ## Introduction
 
 The standard library [`Unmanaged<Instance>` struct](https://github.com/apple/swift/blob/master/stdlib/public/core/Unmanaged.swift) provides a type-safe object wrapper that does not participate in ARC; it allows the user to make manual retain/release calls.
 
-[Swift Evolution Discussion](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001046.html), [Proposed Rewrite Discussion](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003243.html), [Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016034.html)
+[Swift Evolution Discussion](https://forums.swift.org/t/unmanaged-and-copaquepointer-vs-unsafe-mutable-pointer/295), [Proposed Rewrite Discussion](https://forums.swift.org/t/rfc-proposed-rewrite-of-unmanaged-t/612), [Review](https://forums.swift.org/t/review-se-0017-change-unmanaged-to-use-unsafepointer/2380)
 
 ## Motivation
 
@@ -83,5 +83,5 @@ Code previously calling `Unmanaged` API with `COpaquePointer` will need to chang
 
 ## Alternatives considered
 
-- Make no change. However, it has been [said on swift-evolution](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001096.html) that `COpaquePointer` is vestigial, and better bridging of C APIs is desired, so we do want to move in this direction.
+- Make no change. However, it has been [said on swift-evolution](https://forums.swift.org/t/unmanaged-and-copaquepointer-vs-unsafe-mutable-pointer/295/3) that `COpaquePointer` is vestigial, and better bridging of C APIs is desired, so we do want to move in this direction.