Gardening: remove trailing whitespaces (#197)

.github/ISSUE_TEMPLATE/bug_report.md

@@ -55,6 +55,6 @@ Steps to reproduce the behavior:
 
 <!-- Git hash of the site if applicable -->
 
-## Additional context 
+## Additional context
 
 <!-- Add any other context about the problem here. -->

_posts/2016-01-29-swift-api-transformation.md

@@ -15,7 +15,7 @@ things just look *different*, often needlessly so. This is no mere
 aesthetic concern; non-uniformity and lack of predictability make
 everything harder, from coding to debugging to maintenance.
 Fortunately Swift developers created tons of great code in spite of
-that gap, and along the way, there evolved a sense of what 
+that gap, and along the way, there evolved a sense of what
 “Swifty” code looks and feels like.
 
 Informed by that experience, when looking at our APIs, it's easy to
@@ -77,15 +77,15 @@ changes this call:
 
 ~~~swift
 path.addArcWithCenter(
-  origin, radius: 20.0, 
+  origin, radius: 20.0,
   startAngle: 0.0, endAngle: CGFloat(M_PI) * 2.0, clockwise: true)
 ~~~
 
 into this:
 
 ~~~swift
 path.addArc(
-  center: origin, radius: 20.0, 
+  center: origin, radius: 20.0,
   startAngle: 0.0, endAngle: CGFloat(M_PI) * 2.0, clockwise: true)
 ~~~
 

_posts/2016-02-01-swift-CI.md

@@ -6,7 +6,7 @@ title: Continuous Integration now Available
 author: najacque
 ---
 
-We are excited to announce that we have rolled out [continuous integration]({{ site.url }}/continuous-integration) (aka, CI) for the Swift project!  
+We are excited to announce that we have rolled out [continuous integration]({{ site.url }}/continuous-integration) (aka, CI) for the Swift project!
 
 Our CI system is powered by [Jenkins](https://jenkins-ci.org).  For Apple's platforms it builds and runs tests for macOS and the iOS simulator.  For Linux it builds and runs tests for Ubuntu 14.04 and Ubuntu 15.10 (both for x86_64).  In addition to using it for testing active branches, the CI system also produces the snapshots that are available for download from Swift.org.
 
@@ -33,7 +33,7 @@ If there are issues found during testing, you will get a link to the details of
 In the near future, we will also be supporting running performance tests.  We also welcome community involvement to help us expand testing to additional configurations.
 
 
-  
+
 
 
 

_posts/2016-05-06-swift-3.0-release-process.md

@@ -19,10 +19,10 @@ Swift 3.0 is also the first release to include the [Swift Package Manager]({{
 site.url }}/package-manager/).  While the Swift Package Manager is still early
 in its development, it supports the development and distribution of
 cross-platform Swift packages.  The Swift Package Manager will be available on
-both Darwin and Linux. 
+both Darwin and Linux.
 
 For Linux, Swift 3 will also be the first release to contain the [Swift Core
-Libraries]({{ site.url }}/core-libraries/). 
+Libraries]({{ site.url }}/core-libraries/).
 
 Swift 3.0 is expected to be released sometime in late 2016. In addition to its
 Swift.org release, Swift 3.0 will ship in a future version of Xcode.
@@ -84,7 +84,7 @@ Swift.org release, Swift 3.0 will ship in a future version of Xcode.
 - The first developer preview branch `swift-3.0-preview-1-branch` will
   be created from `master` on **May 12**.  It will be released 4-6 weeks
   later.
-  
+
 - The date for creating the last developer preview branch
   — `swift-3.0-branch` — has
   not yet been established.  When that date is determined the plan will be

_posts/2016-06-13-swift-3.0-preview-1-released.md

@@ -85,6 +85,6 @@ This should be resolved in a future beta.
 ### Migrating to Swift 3
 
 Swift 3 is a source-breaking release over Swift 2.2.1.  It contains many syntactic refinements and improvements,
-but also a huge number of changes for how Objective-C APIs import into Swift due to [SE-0005](https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md). 
+but also a huge number of changes for how Objective-C APIs import into Swift due to [SE-0005](https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md).
 Please consult the [migration guide]({{ site.url }}/migration-guide/) for guidance and tips
 for migrating to Swift 3.

_posts/2016-10-21-whole-module-optimizations.md

@@ -56,7 +56,7 @@ With whole-module optimization the compiler can do a lot better. When compiling
 
 ![whole-module compilation]({{ site.url }}/assets/images/wmo-blog/wmo.png)
 
-This has two big advantages. First, the compiler sees the implementation of all functions in a module, so it can perform optimizations like function inlining and function specialization. 
+This has two big advantages. First, the compiler sees the implementation of all functions in a module, so it can perform optimizations like function inlining and function specialization.
 Function specialization means that the compiler creates a new version of a function which is optimized for a specific call-context. For example, the compiler can specialize a generic function for concrete types.
 
 In our example, the compiler produces a version of the generic `Container` which is specialized for the concrete type `Int`.
@@ -71,7 +71,7 @@ struct Container {
 }
 ~~~
 
-Then the compiler can inline the specialized `getElement` function into the `add` function. 
+Then the compiler can inline the specialized `getElement` function into the `add` function.
 
 ~~~swift
 func add (c1: Container<Int>, c2: Container<Int>) -> Int {
@@ -104,7 +104,7 @@ Internally the compiler runs in multiple phases: parser, type checking, SIL opti
 
 Parsing and type checking is very fast in most cases, and we expect it to get even faster in subsequent Swift releases.
 The SIL optimizer (SIL stands for “Swift Intermediate Language”) performs all the important Swift-specific optimizations, like generic specialization, function inlining, etc. This phase of the compiler typically takes about one third of the compilation time.
-Most of the compilation time is consumed by the LLVM backend which runs lower-level optimizations and does the code generation. 
+Most of the compilation time is consumed by the LLVM backend which runs lower-level optimizations and does the code generation.
 
 After performing whole-module optimizations in the SIL optimizer the module is split again into multiple parts. The LLVM backend processes the split parts in multiple threads. It also avoids re-processing of a part if that part didn’t change since the previous build.
 So even with whole-module optimizations, the compiler is able to perform a big part of the compilation work in parallel (multi-threaded) and incrementally.

_posts/2016-12-9-swift-3.1-release-process.md

@@ -25,13 +25,13 @@ Please file [bug reports](https://bugs.swift.org) if you encounter cases where t
 
 Previous releases of Swift have had "Developer Previews", e.g. "Preview 1", "Preview 2", etc., that represent stabilized snapshots of a Swift release as it converges.  Developer previews have often been irregularly spaced apart, and have sometimes not provided enough granularity for the Swift community to try out new features or verify bug fixes in a release as it converges.
 
-For Swift 3.1 there will instead be daily downloadable snapshots of the release branch.  Snapshots will be produced as part of [continuous integration](https://ci.swift.org) testing.  The cadence of downloadable snapshots will thus be more frequent and granular.  Snapshots will be posted daily, assuming tests are passing. 
+For Swift 3.1 there will instead be daily downloadable snapshots of the release branch.  Snapshots will be produced as part of [continuous integration](https://ci.swift.org) testing.  The cadence of downloadable snapshots will thus be more frequent and granular.  Snapshots will be posted daily, assuming tests are passing.
 
 Once Swift 3.1 is released, official final builds will also be posted in addition to the snapshots.
 
 ## Getting Changes into Swift 3.1
 
-Swift 3.1 is intended to be limited in scope, with the desire to move focus early in 2017 to the development of Swift 4.  To meet this goal, Swift 3.1 will include changes in mainline development (i.e. the `master` branch) only until January 16.  After that date there will be a "bake" period in which only select, critical fixes will go into the `swift-3.1-branch` and move `master` on to Swift 4 development.  
+Swift 3.1 is intended to be limited in scope, with the desire to move focus early in 2017 to the development of Swift 4.  To meet this goal, Swift 3.1 will include changes in mainline development (i.e. the `master` branch) only until January 16.  After that date there will be a "bake" period in which only select, critical fixes will go into the `swift-3.1-branch` and move `master` on to Swift 4 development.
 
 ### Branches
 

_posts/2017-09-19-swift-4.0-released.md

@@ -6,7 +6,7 @@ title: Swift 4.0 Released!
 author: tkremenek
 ---
 
-Swift 4 is now officially released!  Swift 4 builds on the strengths of Swift 3, delivering greater robustness and stability, providing source code compatibility with Swift 3, making improvements to the standard library, and adding features like archival and serialization.  
+Swift 4 is now officially released!  Swift 4 builds on the strengths of Swift 3, delivering greater robustness and stability, providing source code compatibility with Swift 3, making improvements to the standard library, and adding features like archival and serialization.
 
 You can watch a quick overview of it by watching the [WWDC 2017: What's New in Swift](https://developer.apple.com/videos/play/wwdc2017/402/) presentation, and try out some of the new features in this [playground](https://github.com/ole/whats-new-in-swift-4) put together by Ole Begemann.
 

_posts/2017-10-04-dictionary-and-set-improvements.md

@@ -57,7 +57,7 @@ to build and transform dictionaries with these new tools.
 ## Grouping Values by a Key
 
 <img
-  alt="Grouping groceries by their department" 
+  alt="Grouping groceries by their department"
   src="{{ site.url }}/assets/images/dictionary-blog/grouping.png"
   srcset="{{ site.url }}/assets/images/dictionary-blog/grouping_2x.png 2x"
   class="dictionary-blog" />
@@ -117,19 +117,19 @@ let departmentCounts = groceriesByDepartment.mapValues { items in items.count }
 // departmentCounts[.bakery] == 2
 ~~~
 
-Because the dictionary has all the same keys, 
-just with different values, 
-it can use the same internal layout as the original dictionary 
-and doesn't need to recompute any hash values. 
-This makes calling `mapValues(_:)` faster 
+Because the dictionary has all the same keys,
+just with different values,
+it can use the same internal layout as the original dictionary
+and doesn't need to recompute any hash values.
+This makes calling `mapValues(_:)` faster
 than rebuilding the dictionary from scratch.
 
 ## Building Dictionaries from Key-Value Pairs
 
-<img 
-  alt="Building a dictionary from names and values" 
-  src="{{ site.url }}/assets/images/dictionary-blog/uniqueKeys.png" 
-  srcset="{{ site.url }}/assets/images/dictionary-blog/uniqueKeys_2x.png 2x" 
+<img
+  alt="Building a dictionary from names and values"
+  src="{{ site.url }}/assets/images/dictionary-blog/uniqueKeys.png"
+  srcset="{{ site.url }}/assets/images/dictionary-blog/uniqueKeys_2x.png 2x"
   class="dictionary-blog" />
 
 You can now create dictionaries
@@ -139,8 +139,8 @@ one for when you have unique keys,
 and one for when you might have keys that repeat.
 
 If you start with a sequence of keys and a sequence of values,
-you can combine them 
-into a single sequence of pairs 
+you can combine them
+into a single sequence of pairs
 using the `zip(_:_:)` function.
 For example,
 this code creates a sequence of tuples
@@ -279,10 +279,10 @@ In addition to easier incremental changes,
 dictionaries now make it simpler to make changes in bulk,
 with methods that merge one dictionary into another.
 
-<img 
-  alt="Merging two carts together" 
-  src="{{ site.url }}/assets/images/dictionary-blog/merging.png" 
-  srcset="{{ site.url }}/assets/images/dictionary-blog/merging_2x.png 2x" 
+<img
+  alt="Merging two carts together"
+  src="{{ site.url }}/assets/images/dictionary-blog/merging.png"
+  srcset="{{ site.url }}/assets/images/dictionary-blog/merging_2x.png 2x"
   class="dictionary-blog" />
 
 To merge the contents of `cart` and another dictionary,

_posts/2017-10-17-swift-4.1-release-process.md

@@ -20,7 +20,7 @@ The vast majority of sources that built with the Swift 4.0 compiler (including t
 
 ## Snapshots of Swift 4.1
 
-Downloadable snapshots of the Swift 4.1 release branch will be posted regularly as part of [continuous integration](https://ci.swift.org) testing. 
+Downloadable snapshots of the Swift 4.1 release branch will be posted regularly as part of [continuous integration](https://ci.swift.org) testing.
 
 Once Swift 4.1 is released the official final builds will also be posted in addition to the snapshots.
 

_posts/2017-2-16-swift-4.0-release-process.md

@@ -43,13 +43,13 @@ A more detailed description of the intent for source compatibility for Swift rel
 
 ## Snapshots of Swift 4
 
-As in the case of Swift 3.1, for Swift 4 there will be daily downloadable snapshots of the release branch.  Snapshots will be produced as part of [continuous integration](https://ci.swift.org) testing.  The cadence of downloadable snapshots will thus be more frequent and granular.  Snapshots will be posted daily, assuming tests are passing. 
+As in the case of Swift 3.1, for Swift 4 there will be daily downloadable snapshots of the release branch.  Snapshots will be produced as part of [continuous integration](https://ci.swift.org) testing.  The cadence of downloadable snapshots will thus be more frequent and granular.  Snapshots will be posted daily, assuming tests are passing.
 
 Once Swift 4 is released, official final builds will also be posted in addition to the snapshots.
 
 ## Getting Changes into Swift 4
 
-All changes currently going into mainline development (i.e. the `master` branch) until a final branch date is announced by the release manager, which will likely be sometime in early summer of 2017.  After that point there will be a "bake" period in which only select, critical fixes will go into the `swift-4.0-branch` and move `master` on to developement for the next release.  
+All changes currently going into mainline development (i.e. the `master` branch) until a final branch date is announced by the release manager, which will likely be sometime in early summer of 2017.  After that point there will be a "bake" period in which only select, critical fixes will go into the `swift-4.0-branch` and move `master` on to developement for the next release.
 
 ### Branches
 

_posts/2017-3-27-swift-3.1-released.md

@@ -6,7 +6,7 @@ title: Swift 3.1 Released!
 author: allendenison
 ---
 
-Swift 3.1 is now officially released!  Swift 3.1 is a minor release that contains improvements and refinements to the Standard Library. Thanks to efforts by IBM and other members of the community, it also includes many updates to the Linux implementation of Swift.  There are also a number of updates to Swift Package Manager.  
+Swift 3.1 is now officially released!  Swift 3.1 is a minor release that contains improvements and refinements to the Standard Library. Thanks to efforts by IBM and other members of the community, it also includes many updates to the Linux implementation of Swift.  There are also a number of updates to Swift Package Manager.
 
 ### Language Updates
 Swift 3.1 is a minor language release.  It is source compatible with Swift 3.0.  It contains the following language changes and updates, most of which went through the Swift [Evolution process](https://swift.org/contributing/#participating-in-the-swift-evolution-process):
@@ -56,7 +56,7 @@ See more at: [SE-0147: Move UnsafeMutablePointer.initialize(from:) to UnsafeMuta
 * Implementation of `NSDecimal`
 * Implementation of `NSLengthFormatter`
 * Implementation of `Progress`
-* Many improvements to `URLSession` functionality, including API coverage and optimized usage of `libdispatch`  
+* Many improvements to `URLSession` functionality, including API coverage and optimized usage of `libdispatch`
 * Improved API coverage in `NSArray`, `NSAttributedString` and many others
 * Significant performance improvements in `Data`. [See more details here](https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/Performance%20Refinement%20of%20Data.md)
 * Improved JSON serialization performance

_posts/2018-01-08-conditional-conformance.md

@@ -42,7 +42,7 @@ This was possible via overloads of the `==` operator, like this one for `Array`:
 extension Array where Element: Equatable {
     public static func ==(lhs: [Element], rhs: [Element]) -> Bool {
         return lhs.elementsEqual(rhs)
-    }  
+    }
 }
 ~~~
 
@@ -61,7 +61,7 @@ let a = ["1","2","x"].map(Int.init)
 a == [1,2,nil]    // expecting 'true'
 ~~~
 
-You'd get a compiler error: 
+You'd get a compiler error:
 
 > Binary operator '==' cannot be applied to two '[Int?]' operands.
 
@@ -189,15 +189,15 @@ start of the next subsequence in the base, or the end.
 extension LazySplitCollection: Collection {
     typealias Element = Base.SubSequence
     typealias Index = Base.Index
-  
+
     var startIndex: Index { return base.startIndex }
     var endIndex: Index { return base.endIndex }
-  
+
     subscript(i: Index) -> Element {
         let separator = base[i...].index(where: isSeparator)
         return base[i..<(separator ?? endIndex)]
     }
-  
+
     func index(after i: Index) -> Index {
         let separator = base[i...].index(where: isSeparator)
         return separator.map(base.index(after:)) ?? endIndex
@@ -212,7 +212,7 @@ collection from the given index for the next separator. If there isn't one,
 substitute the end index in that case. The only fiddly part is skipping over
 the separator in the `index(after:)` implementation, which we do with an
  [optional map][Optional.map].
- 
+
 ### Extending lazy
 
 Now that we have this wrapper, we want to extend all the lazy collection types

_posts/2018-01-19-forums.md

@@ -26,7 +26,7 @@ Some of these categories, such as the announcement and CI Notification sub-categ
 In addition to categories, forum posts can also be categorized by use of tags.  A forum post can have many different tags added by the poster.  This is a great way to make it easy to find posts relating to certain topics, and to mark topics of interest (such as issues relating to specific projects) so that they can be easily found.
 
 ####Accounts
-Accounts can be set up using either email registration, or GitHub accounts.  For those who have previously sent messages to the various Swift mailing lists, a staged account will already be set up, and you can [take control of the account](https://forums.swift.org/faq), provided you still have control of that email address.  
+Accounts can be set up using either email registration, or GitHub accounts.  For those who have previously sent messages to the various Swift mailing lists, a staged account will already be set up, and you can [take control of the account](https://forums.swift.org/faq), provided you still have control of that email address.
 
 Within the forums, users can be tagged as “@Username” and can get notifications based on that tagging.
 
@@ -37,8 +37,8 @@ You can choose to get email notifications for tracked categories tags, and can a
 All forum activity is expected to conform to the Swift Code of Conduct.  The Code of Conduct will be prominently posted on the site. Violations can be anonymously flagged via the forum for review by administrators.
 
 ####FAQ
-Please visit the [FAQ](https://forums.swift.org/faq) for  answers to common questions, procedures, and links.  
-  
+Please visit the [FAQ](https://forums.swift.org/faq) for  answers to common questions, procedures, and links.
+
 
 
 

_posts/2018-02-08-osize.md

@@ -29,7 +29,7 @@ But what about performance? This completely depends on the project. For most app
 
 Let's go into the details on what the compiler does differently with `-Osize`.
 With `-Osize` the compiler optimizes the code, just like with `-O`.
-But in contrast to `-O`, the compiler tries to avoid code duplication. For example, when inlining functions the compiler uses a lower size limit to decide whether a function should be inlined. 
+But in contrast to `-O`, the compiler tries to avoid code duplication. For example, when inlining functions the compiler uses a lower size limit to decide whether a function should be inlined.
 
 Completely disabling function inlining would be a bad idea, because inlining small functions often improve code size. For example consider simple getter functions, like
 

_posts/2018-04-26-iuo.md

@@ -140,7 +140,7 @@ For the following example, previous versions of Swift inferred the type of `labe
 
 ~~~swift
 // label is inferred to be UILabel?
-if let label = object.property { 
+if let label = object.property {
    // Error due to passing a UILabel? where a UILabel is expected
   functionTakingLabel(label)
 }