swiftlang · beccadax · Jan 17, 2021 · Jan 17, 2021
diff --git a/proposals/0047-nonvoid-warn.md b/proposals/0047-nonvoid-warn.md
@@ -145,5 +145,5 @@ Upon acceptance, this proposal removes two of the last remaining instances of sn
 
 ## Acknowledgements
 
-Changing the behavior of non-void functions to use default warnings for unused results was initially introduced by Adrian Kashivskyy. Additional thanks go out to Chris Lattner, Gwendal Roué, Dmitri Gribenko, Jeff Kelley, David Owens, Jed Lewison, Stephen Cellis, Ankit Aggarwal, Paul Ossenbruggen,Brent Royal-Gordon, Tino Heth, Haravikk, Félix Cloutier,Yuta Koshizawa, 
+Changing the behavior of non-void functions to use default warnings for unused results was initially introduced by Adrian Kashivskyy. Additional thanks go out to Chris Lattner, Gwendal Roué, Dmitri Gribenko, Jeff Kelley, David Owens, Jed Lewison, Stephen Cellis, Ankit Aggarwal, Paul Ossenbruggen, Becca Royal-Gordon, Tino Heth, Haravikk, Félix Cloutier,Yuta Koshizawa, 
 for their feedback on this topic.
diff --git a/proposals/0056-trailing-closures-in-guard.md b/proposals/0056-trailing-closures-in-guard.md
@@ -90,7 +90,7 @@ There are four primary alternatives:
    in the Swift 2 timeframe.  I feel that it has stood the test of time well
    since then.
 
- * *Change the syntax of `if` and `while`*: Brent Royal-Gordon points out that
+ * *Change the syntax of `if` and `while`*: Becca Royal-Gordon points out that
    we could change `if` and `while` to use a keyword after their condition as
    well, e.g.:
 

diff --git a/proposals/0068-universal-self.md b/proposals/0068-universal-self.md
@@ -57,7 +57,7 @@ Not at this time
 
 ## Acknowledgements
 
-Thanks Sean Heber, Lily Ballard, Joe Groff, Timothy Wood, Brent Royal-Gordon, Andrey Tarantsov, Austin Zheng
+Thanks Sean Heber, Lily Ballard, Joe Groff, Timothy Wood, Becca Royal-Gordon, Andrey Tarantsov, Austin Zheng
 
 ## Rationale
 

diff --git a/proposals/0084-trailing-commas.md b/proposals/0084-trailing-commas.md
@@ -79,7 +79,7 @@ Allowing cut and paste or commenting of entire parameter lines means simple chan
 
 > "Having used, more or less continuously for my 20 years as a professional programmer, both a language that allows trailing commas and one that does not, I come down pretty strongly on the side of allowing trailing commas (for all the reasons already stated in this thread). If it means requiring a newline after the last comma to make some people feel better about it, so be it."  - John Siracusa
 
-> "I was skeptical of this until a week or two ago, when I had some code where I ended up commenting out certain parameters. Removing the now-trailing commas was an inconvenience. So, +1 from me." - Brent Royal-Gordon
+> "I was skeptical of this until a week or two ago, when I had some code where I ended up commenting out certain parameters. Removing the now-trailing commas was an inconvenience. So, +1 from me." - Becca Royal-Gordon
 
 > "We should be consistent in either accepting or rejecting trailing commas everywhere we have comma-delimited syntax. I'm in favor of accepting it, since it's popular in languages where it's supported to enable a minimal-diff style, so that changes to code don't impact neighboring lines for purely syntactic reasons.
 >

diff --git a/proposals/0089-rename-string-reflection-init.md b/proposals/0089-rename-string-reflection-init.md
@@ -1,7 +1,7 @@
 # Renaming `String.init<T>(_: T)`
 
 * Proposal: [SE-0089](0089-rename-string-reflection-init.md)
-* Authors: [Austin Zheng](https://github.com/austinzheng), [Brent Royal-Gordon](https://github.com/brentdax)
+* Authors: [Austin Zheng](https://github.com/austinzheng), [Becca Royal-Gordon](https://github.com/beccadax)
 * Review Manager: [Chris Lattner](http://github.com/lattner)
 * Status: **Implemented (Swift 3)**
 * Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000190.html)

diff --git a/proposals/0095-any-as-existential.md b/proposals/0095-any-as-existential.md
@@ -72,5 +72,5 @@ The original proposal suggested replacing `protocol<>` with either `Any<>` or `a
 
 ## Acknowledgements
 
-[Matthew Johnson](https://github.com/anandabits) and [Brent Royal-Gordon](https://github.com/brentdax) provided valuable input which helped shape the first version of this proposal.
+[Matthew Johnson](https://github.com/anandabits) and [Becca Royal-Gordon](https://github.com/beccadax) provided valuable input which helped shape the first version of this proposal.
 
diff --git a/proposals/0105-remove-where-from-forin-loops.md b/proposals/0105-remove-where-from-forin-loops.md
@@ -153,4 +153,4 @@ Code must be refactored to move the where clause into `guard` (or, for less styl
 
 ## Acknowledgements
 
-Big thanks to Joe Groff, Brent Royal-Gordon, Xiaodi Wu
+Big thanks to Joe Groff, Becca Royal-Gordon, Xiaodi Wu
diff --git a/proposals/0132-sequence-end-ops.md b/proposals/0132-sequence-end-ops.md
@@ -1,7 +1,7 @@
 # Rationalizing Sequence end-operation names
 
 * Proposal: [SE-0132](0132-sequence-end-ops.md)
-* Authors: [Brent Royal-Gordon](https://github.com/brentdax), [Dave Abrahams](https://github.com/dabrahams)
+* Authors: [Becca Royal-Gordon](https://github.com/beccadax), [Dave Abrahams](https://github.com/dabrahams)
 * Review Manager: [Chris Lattner](http://github.com/lattner)
 * Status: **Rejected**
 * Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000267.html)

diff --git a/proposals/0148-generic-subscripts.md b/proposals/0148-generic-subscripts.md
@@ -64,7 +64,7 @@ Adding default arguments would unify the compiler's handling of subscripts and f
 
 ## Source compatibility
 
-This is a purely additive change. We don't propose changing the Standard Library to use this new feature, that should be part of a separate proposal. (Likewise, we should consider making subscripts `throws` in a [separate proposal](https://github.com/brentdax/swift-evolution/blob/throwing-properties/proposals/0000-throwing-properties.md)).
+This is a purely additive change. We don't propose changing the Standard Library to use this new feature, that should be part of a separate proposal. (Likewise, we should consider making subscripts `throws` in a [separate proposal](https://github.com/beccadax/swift-evolution/blob/throwing-properties/proposals/0000-throwing-properties.md)).
 
 ## Effect on ABI stability
 

diff --git a/proposals/0168-multi-line-string-literals.md b/proposals/0168-multi-line-string-literals.md
@@ -1,7 +1,7 @@
 # Multi-Line String Literals
 
 * Proposal: [SE-0168](0168-multi-line-string-literals.md)
-* Authors: [John Holdsworth](https://github.com/johnno1962), [Brent Royal-Gordon](https://github.com/brentdax), [Tyler Cloutier](https://github.com/TheArtOfEngineering)
+* Authors: [John Holdsworth](https://github.com/johnno1962), [Becca Royal-Gordon](https://github.com/beccadax), [Tyler Cloutier](https://github.com/TheArtOfEngineering)
 * Review Manager: [Joe Groff](https://github.com/jckarter)
 * Status: **Implemented (Swift 4)**
 * Implementation: [apple/swift#8813](https://github.com/apple/swift/pull/8813)

diff --git a/proposals/0172-one-sided-ranges.md b/proposals/0172-one-sided-ranges.md
@@ -1,7 +1,7 @@
 # One-sided Ranges
 
 * Proposal: [SE-0172](0172-one-sided-ranges.md)
-* Authors: [Ben Cohen](https://github.com/airspeedswift), [Dave Abrahams](https://github.com/dabrahams), [Brent Royal-Gordon](https://github.com/brentdax)
+* Authors: [Ben Cohen](https://github.com/airspeedswift), [Dave Abrahams](https://github.com/dabrahams), [Becca Royal-Gordon](https://github.com/beccadax)
 * Review Manager: [Doug Gregor](https://github.com/DougGregor)
 * Status: **Implemented (Swift 4)** 
 * Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170424/036125.html)

diff --git a/proposals/0192-non-exhaustive-enums.md b/proposals/0192-non-exhaustive-enums.md
@@ -468,7 +468,7 @@ I didn't have a strong preference for any particular choice as long as it *isn't
 
 Note that "nonextensible" does have one problem: Apple already uses [`NS_TYPED_EXTENSIBLE_ENUM `][NS_TYPED_EXTENSIBLE_ENUM] to refer to enum-like sets of constants (usually strings) that *clients* can add "cases" to. That's not the same meaning as the exhaustiveness discussed in this proposal.
 
-During the first review for this proposal, Brent Royal-Gordon suggested "frozen", which was met with general approval or at least no major objections.
+During the first review for this proposal, Becca Royal-Gordon suggested "frozen", which was met with general approval or at least no major objections.
 
   [NS_TYPED_EXTENSIBLE_ENUM]: https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithCAPIs.html#//apple_ref/doc/uid/TP40014216-CH8-ID206
 
@@ -538,7 +538,7 @@ unknown:
 
 ### Testing invalid cases
 
-Another issue with non-frozen enums is that clients cannot properly test what happens when a new case is introduced, almost by definition. Brent Royal-Gordon came up with the idea to have a new type annotation that would allow the creation of an invalid enum value. Since this is only something to use for testing, the initial version of the idea used `@testable` as the spelling for the annotation. The tests could then use a special expression, `#invalid`, to pass this invalid value to a function with a `@testable` enum parameter.
+Another issue with non-frozen enums is that clients cannot properly test what happens when a new case is introduced, almost by definition. Becca Royal-Gordon came up with the idea to have a new type annotation that would allow the creation of an invalid enum value. Since this is only something to use for testing, the initial version of the idea used `@testable` as the spelling for the annotation. The tests could then use a special expression, `#invalid`, to pass this invalid value to a function with a `@testable` enum parameter.
 
 However, this would only work in cases where the action to be taken does not actually depend on the enum value. If it needs to be passed to the original library that owns the enum, or used with an API that is not does not have this annotation, the code still cannot be tested properly.
 

diff --git a/proposals/0194-derived-collection-of-enum-cases.md b/proposals/0194-derived-collection-of-enum-cases.md
@@ -1,7 +1,7 @@
 # Derived Collection of Enum Cases
 
 * Proposal: [SE-0194](0194-derived-collection-of-enum-cases.md)
-* Authors: [Jacob Bandes-Storch](https://github.com/jtbandes), [Brent Royal-Gordon](https://github.com/brentdax), [Robert Widmann](https://github.com/CodaFi)
+* Authors: [Jacob Bandes-Storch](https://github.com/jtbandes), [Becca Royal-Gordon](https://github.com/beccadax), [Robert Widmann](https://github.com/CodaFi)
 * Review Manager: [Doug Gregor](https://github.com/DougGregor)
 * Review Thread: [SE-0194 review][se8]
 * Status: **Implemented (Swift 4.2)**

diff --git a/proposals/0200-raw-string-escaping.md b/proposals/0200-raw-string-escaping.md
@@ -1,7 +1,7 @@
 # Enhancing String Literals Delimiters to Support Raw Text
 
 * Proposal: [SE-0200](0200-raw-string-escaping.md)
-* Authors: [John Holdsworth](https://github.com/johnno1962), [Brent Royal-Gordon](https://github.com/brentdax), [Erica Sadun](https://github.com/erica)
+* Authors: [John Holdsworth](https://github.com/johnno1962), [Becca Royal-Gordon](https://github.com/beccadax), [Erica Sadun](https://github.com/erica)
 * Review Manager: [Doug Gregor](https://github.com/DougGregor)
 * Previous Revision: [1](https://github.com/apple/swift-evolution/blob/102b2f2770f0dab29f254a254063847388647a4a/proposals/0200-raw-string-escaping.md)
 * Status: **Implemented (Swift 5)**

diff --git a/proposals/0225-binaryinteger-iseven-isodd-ismultiple.md b/proposals/0225-binaryinteger-iseven-isodd-ismultiple.md
@@ -178,7 +178,7 @@ For some user-defined types, especially bignum types, you may want to implement
 * [Precondition check in sqlite function](https://github.com/sqlcipher/sqlcipher/blob/c6f709fca81c910ba133aaf6330c28e01ccfe5f8/src/crypto_impl.c#L1296)
 * [Alternating UITableView cell background style](https://github.com/alloy/HockeySDK-CocoaPods/blob/978f3f072d206cfa35f4789d3a5b3abb31b9df11/Pods/HockeySDK/Classes/BITFeedbackListViewController.m#L502). NSTableView [has built in support](https://developer.apple.com/documentation/appkit/nstableview/1533967-usesalternatingrowbackgroundcolo?language=objc) for this.
 * [Barcode reading](https://github.com/TheLevelUp/ZXingObjC/blob/d952cc02beb948ab49832661528c5e3e4953885e/ZXingObjC/oned/rss/expanded/ZXRSSExpandedReader.m#L449)
-* [CSS row and column styling](https://www.w3.org/Style/Examples/007/evenodd.en.html) with `nth-child(even)` and `nth-child(odd)` (h/t @brentdax)
+* [CSS row and column styling](https://www.w3.org/Style/Examples/007/evenodd.en.html) with `nth-child(even)` and `nth-child(odd)` (h/t @beccadax)
 * Various test code
 
 Some _really_ real-world examples:

diff --git a/proposals/0228-fix-expressiblebystringinterpolation.md b/proposals/0228-fix-expressiblebystringinterpolation.md
@@ -1,7 +1,7 @@
 # Fix `ExpressibleByStringInterpolation`
 
 * Proposal: [SE-0228](0228-fix-expressiblebystringinterpolation.md)
-* Authors: [Brent Royal-Gordon](https://github.com/brentdax), [Michael Ilseman](https://github.com/milseman)
+* Authors: [Becca Royal-Gordon](https://github.com/beccadax), [Michael Ilseman](https://github.com/milseman)
 * Review Manager: [Doug Gregor](https://github.com/DougGregor)
 * Status: **Implemented (Swift 5)**
 * Review: [Discussion thread](https://forums.swift.org/t/se-0228-fix-expressible-by-string-interpolation/16031), [Announcement thread](https://forums.swift.org/t/accepted-se-0228-fix-expressible-by-string-interpolation/16548)
@@ -33,9 +33,9 @@ We see three general classes of types that might want to conform to `Expressible
 
 The current design handles simple textual data, but struggles to support structured textual data and machine-readable code fragments.
 
-  [sql]: https://github.com/brentdax/SQLKit/blob/master/Sources/SQLKit/SQLStatement.swift
+  [sql]: https://github.com/beccadax/SQLKit/blob/master/Sources/SQLKit/SQLStatement.swift
   [html]: https://oleb.net/blog/2017/01/fun-with-string-interpolation/
-  [loc]: https://gist.github.com/brentdax/79fa038c0af0cafb52dd
+  [loc]: https://gist.github.com/beccadax/79fa038c0af0cafb52dd
 
 ### Current design
 
@@ -188,7 +188,7 @@ String(stringInterpolation: {
 
 [We have written a few examples of conforming types.][examples]
 
-  [examples]: https://gist.github.com/brentdax/0b46ce25b7da1049e61b4669352094b6
+  [examples]: https://gist.github.com/beccadax/0b46ce25b7da1049e61b4669352094b6
 
 ## Detailed design
 

diff --git a/proposals/0254-static-subscripts.md b/proposals/0254-static-subscripts.md
@@ -1,7 +1,7 @@
 # Static and class subscripts
 
 * Proposal: [SE-0254](0254-static-subscripts.md)
-* Author: [Brent Royal-Gordon](https://github.com/brentdax)
+* Author: [Becca Royal-Gordon](https://github.com/beccadax)
 * Review Manager: [Doug Gregor](https://github.com/DougGregor)
 * Status: **Implemented (Swift 5.1)**
 * Implementation: [apple/swift#23358](https://github.com/apple/swift/pull/23358)

diff --git a/proposals/0258-property-wrappers.md b/proposals/0258-property-wrappers.md
@@ -589,7 +589,7 @@ enum GlobalSettings {
 
 ### Copy-on-write
 
-With some work, property wrappers can provide copy-on-write wrappers (original example courtesy of Brent Royal-Gordon):
+With some work, property wrappers can provide copy-on-write wrappers (original example courtesy of Becca Royal-Gordon):
 
 ```swift
 protocol Copyable: AnyObject {
@@ -1569,4 +1569,4 @@ One could express this either by naming the property directly (as above) or, for
 
 ## Acknowledgments
 
-This proposal was greatly improved throughout its [first pitch](https://forums.swift.org/t/pitch-property-delegates/21895) by many people. Harlan Haskins, Brent Royal-Gordon, Adrian Zubarev, Jordan Rose and others provided great examples of uses of property wrappers (several of which are in this proposal). Adrian Zubarev and Kenny Leung helped push on some of the core assumptions and restrictions of the original proposal, helping to make it more general. Vini Vendramini and David Hart helped tie this proposal together with custom attributes, which drastically reduced the syntactic surface area of this proposal.
+This proposal was greatly improved throughout its [first pitch](https://forums.swift.org/t/pitch-property-delegates/21895) by many people. Harlan Haskins, Becca Royal-Gordon, Adrian Zubarev, Jordan Rose and others provided great examples of uses of property wrappers (several of which are in this proposal). Adrian Zubarev and Kenny Leung helped push on some of the core assumptions and restrictions of the original proposal, helping to make it more general. Vini Vendramini and David Hart helped tie this proposal together with custom attributes, which drastically reduced the syntactic surface area of this proposal.
diff --git a/proposals/0274-magic-file.md b/proposals/0274-magic-file.md
@@ -1,7 +1,7 @@
 # Concise magic file names
 
 * Proposal: [SE-0274](0274-magic-file.md)
-* Authors: [Brent Royal-Gordon](https://github.com/brentdax), [Dave DeLong](https://github.com/davedelong)
+* Authors: [Becca Royal-Gordon](https://github.com/beccadax), [Dave DeLong](https://github.com/davedelong)
 * Review Manager: [Ben Cohen](https://github.com/airspeedswift/)
 * Original review: [Returned for revision](https://forums.swift.org/t/se-0274-concise-magic-file-names/32373/50) 
 * Status: **Accepted**
@@ -49,7 +49,7 @@ For `#file`'s most important use case, it seems like the current string computed
 
 We propose changing the string that `#file` evaluates to—instead of evaluating to the full path, it will now have the format `<module-name>/<file-name>`. For those applications which still need a full path, we will provide a new magic identifier, `#filePath`. Both of these features will otherwise behave the same as the old `#file`, including capturing the call site location when used in default arguments. The standard library's assertion and error functions will continue to use `#file`.
 
-With this proposal, a file at `/Users/brent/Desktop/0274-magic-file.swift` in a module named `MagicFile` with this content:
+With this proposal, a file at `/Users/becca/Desktop/0274-magic-file.swift` in a module named `MagicFile` with this content:
 
 ```swift
 print(#file)
@@ -61,7 +61,7 @@ Would produce this output:
 
 ```text
 MagicFile/0274-magic-file.swift
-/Users/brent/Desktop/0274-magic-file.swift
+/Users/becca/Desktop/0274-magic-file.swift
 Fatal error: Something bad happened!: file MagicFile/0274-magic-file.swift, line 3
 ```
 

diff --git a/proposals/0285-ease-pound-file-transition.md b/proposals/0285-ease-pound-file-transition.md
@@ -1,7 +1,7 @@
 # Ease the transition to concise magic file strings
 
 * Proposal: [SE-0285](0285-ease-pound-file-transition.md)
-* Author: [Brent Royal-Gordon](https://github.com/brentdax)
+* Author: [Becca Royal-Gordon](https://github.com/beccadax)
 * Review Manager: [Tom Doron](https://github.com/tomerd)
 * Implementation: [apple/swift#32700](https://github.com/apple/swift/pull/32700)
 * Status: **Implemented (Swift 5.3)**
Original file line number	Diff line number	Diff line change
Expand Up		@@ -72,5 +72,5 @@ The original proposal suggested replacing `protocol<>` with either `Any<>` or `a

		## Acknowledgements

		[Matthew Johnson](https://github.com/anandabits) and [Brent Royal-Gordon](https://github.com/brentdax) provided valuable input which helped shape the first version of this proposal.
		[Matthew Johnson](https://github.com/anandabits) and [Becca Royal-Gordon](https://github.com/beccadax) provided valuable input which helped shape the first version of this proposal.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -153,4 +153,4 @@ Code must be refactored to move the where clause into `guard` (or, for less styl

		## Acknowledgements

		Big thanks to Joe Groff, Brent Royal-Gordon, Xiaodi Wu
		Big thanks to Joe Groff, Becca Royal-Gordon, Xiaodi Wu