Swift 6.1

.git-blame-ignore-revs

@@ -0,0 +1,24 @@
+# This file is a list of commits that made uninteresting formatting
+# changes, which should be ignored by git-blame, so that it can instead
+# display more the relevant history and attribution information.
+#
+# To use this file for a single command, pass it as follows:
+#
+#   git blame --ignore-revs-file .git-blame-ignore-revs <somefile>
+#
+# To use this file for all blame operations, run the following command:
+#
+#   git config --local blame.ignoreRevsFile .git-blame-ignore-revs
+#
+# For more information, see the git-blame(1) man page's discussion of
+# the --ignore-revs-file option, and the git-config(1) man page's
+# discussion of the blame.ignoreRevsFile option.
+
+# Convert RST to markdown
+96f0925407c6bd9eadd9d58d253bad3e1ef7a9f2
+
+# Convert the formal grammar to markdown
+4039ee0ef4e69d2cf6460861f9444a499503db16
+
+# Clean up formatting of term-definition lists
+c914c44ccdbbda757ee43e5d4c777abf24391a1a

.git-order-file

@@ -0,0 +1,66 @@
+# This file lists the chapters of TSPL, in the order they appear in the
+# book.  When reviewing changes, the diff can be easier to read when it
+# appears in this order.
+#
+# To use this file for single command, run a command like the following:
+#
+#     git log -O .git-order-file
+#     git diff -O .git-order-file
+#
+# To use it for all diffs, run the following command:
+#
+#     git config --local diff.orderFile .git-order-file
+#
+# For more information, see the git-log(1) and git-diff(1) man pages'
+# discussions of the -O option, and the git-config(1) man page's
+# discussion of diff.orderFile option.
+
+TSPL.docc/GuidedTour/AboutSwift.md
+TSPL.docc/GuidedTour/Compatibility.md
+TSPL.docc/GuidedTour/GuidedTour.md
+
+TSPL.docc/LanguageGuide/TheBasics.md
+TSPL.docc/LanguageGuide/BasicOperators.md
+TSPL.docc/LanguageGuide/StringsAndCharacters.md
+TSPL.docc/LanguageGuide/CollectionTypes.md
+TSPL.docc/LanguageGuide/ControlFlow.md
+TSPL.docc/LanguageGuide/Functions.md
+TSPL.docc/LanguageGuide/Closures.md
+TSPL.docc/LanguageGuide/Enumerations.md
+TSPL.docc/LanguageGuide/ClassesAndStructures.md
+TSPL.docc/LanguageGuide/Properties.md
+TSPL.docc/LanguageGuide/Methods.md
+TSPL.docc/LanguageGuide/Subscripts.md
+TSPL.docc/LanguageGuide/Inheritance.md
+TSPL.docc/LanguageGuide/Initialization.md
+TSPL.docc/LanguageGuide/Deinitialization.md
+TSPL.docc/LanguageGuide/OptionalChaining.md
+TSPL.docc/LanguageGuide/ErrorHandling.md
+TSPL.docc/LanguageGuide/Concurrency.md
+TSPL.docc/LanguageGuide/Macros.md
+TSPL.docc/LanguageGuide/TypeCasting.md
+TSPL.docc/LanguageGuide/NestedTypes.md
+TSPL.docc/LanguageGuide/Extensions.md
+TSPL.docc/LanguageGuide/Protocols.md
+TSPL.docc/LanguageGuide/Generics.md
+TSPL.docc/LanguageGuide/OpaqueTypes.md
+TSPL.docc/LanguageGuide/AutomaticReferenceCounting.md
+TSPL.docc/LanguageGuide/MemorySafety.md
+TSPL.docc/LanguageGuide/AccessControl.md
+TSPL.docc/LanguageGuide/AdvancedOperators.md
+
+TSPL.docc/ReferenceManual/AboutTheLanguageReference.md
+TSPL.docc/ReferenceManual/LexicalStructure.md
+TSPL.docc/ReferenceManual/Types.md
+TSPL.docc/ReferenceManual/Expressions.md
+TSPL.docc/ReferenceManual/Statements.md
+TSPL.docc/ReferenceManual/Declarations.md
+TSPL.docc/ReferenceManual/Attributes.md
+TSPL.docc/ReferenceManual/Patterns.md
+TSPL.docc/ReferenceManual/GenericParametersAndArguments.md
+TSPL.docc/ReferenceManual/SummaryOfTheGrammar.md
+
+TSPL.docc/RevisionHistory/RevisionHistory.md
+
+# Files that don't match a pattern listed above, such as assets and
+# build scripts, will appear at the end of the diff.

.gitattributes

@@ -0,0 +1,3 @@
+*.md linguist-detectable=true
+*.md linguist-documentation=false
+*.md diff=markdown

.github/ISSUE_TEMPLATE/BUG_REPORT.yml

@@ -0,0 +1,31 @@
+name: Content Issue
+description: Something is missing or incorrect
+labels: ["Content Issue"]
+body:
+- type: markdown
+  attributes:
+    value: |
+      Thank you for contributing to "The Swift Programming Language"!
+
+      Before you submit your issue, please provide the relevant details in the text areas below.
+- type: textarea
+  attributes:
+    label: Location
+    description: |
+      The URL of the content that has a problem.
+  validations:
+    required: false
+- type: textarea
+  attributes:
+    label: Description
+    description: |
+      A short description of what's wrong.
+  validations:
+    required: true
+- type: textarea
+  attributes:
+    label: Correction
+    description: |
+      What should the documentation say instead?
+  validations:
+    required: false

.github/ISSUE_TEMPLATE/FEATURE_REQUEST.yml

@@ -0,0 +1,36 @@
+name: Enhancement
+description: A suggestion for new content
+labels: [Enhancement]
+body:
+- type: markdown
+  attributes:
+    value: |
+      Thank you for contributing to "The Swift Programming Language"!
+
+      Before you submit your issue, please provide the relevant details in the text areas below.
+- type: textarea
+  attributes:
+    label: Location
+    description: |
+      The URL of the chapter or section where the new content would go.
+  validations:
+    required: false
+- type: textarea
+  attributes:
+    label: Description
+    description: |
+      A short description of your proposed addition.
+  validations:
+    required: true
+- type: textarea
+  attributes:
+    label: Motivation
+    description: A description of the use-case this proposed documentation will serve.
+  validations:
+    required: false
+- type: textarea
+  attributes:
+    label: Alternatives Considered
+    description: If you considered alternative approaches, please include them here.
+  validations:
+    required: false

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,12 @@
+blank_issues_enabled: yes
+
+contact_links:
+  - name: Documentation Forums Category
+    url: https://forums.swift.org/c/92
+    about: Ask and answer questions about writing documentation
+  - name: Swift-DocC Forums Category
+    url: https://forums.swift.org/c/80
+    about: Ask and answer questions about using Swift-DocC
+  - name: Swift-DocC Documentation
+    url: https://www.swift.org/documentation/docc/
+    about: Learn about how to use Swift-DocC for authoring documentation

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,8 @@
+<!-- If this pull request incorporates language changes from a Swift Evolution proposal, add the SE number in square brackets at the end of the PR title. -->
+
+<!-- What's in this pull request? -->
+Replace this paragraph with your rationale and a brief summary of what changed.
+
+<!-- Link to the issue that this pull request fixes, if applicable. -->
+Fixes: https://github.com/apple/swift-book/issues/####
+Fixes: rdar://####

.gitignore

@@ -1,6 +1,10 @@
 .DS_Store
+.docc-build
+.swiftpm
+/.build
+/Package.resolved
+/TSPL.docc/header.html
+/swift-book
 node_modules
 package-lock.json
-**/.docc-build
 docs
-

CONTRIBUTING.md

@@ -0,0 +1,103 @@
+# Contributing to *The Swift Programming Language* book
+
+By submitting a pull request,
+you represent that you have the right to license your contribution
+to Apple and the community,
+and agree by submitting the patch
+that your contributions are licensed under
+the [Swift license](https://swift.org/LICENSE.txt).
+
+For small changes,
+like typo fixes and revisions within a few paragraphs,
+the discussion of those changes is usually small enough
+to be part of the pull request.
+For large changes,
+like new chapters and sections,
+start a thread in the [Swift forums][forum]
+to discuss your approach and identify possible issues
+before you invest a lot of time in writing.
+In general,
+the amount of discussion around a change before making a pull request
+corresponds to the size of that change.
+
+Content in this book follows [Apple Style Guide][asg]
+and [this book’s style guide][tspl-style].
+
+[asg]: https://help.apple.com/applestyleguide/
+[forum]: https://forums.swift.org/c/swift-documentation/92
+[tspl-style]: /Style.md
+
+## Working on a feature branch
+
+If this is your first contribution,
+start by making a fork of the Git repository.
+
+In your fork,
+make a new branch starting at `main`
+with a brief, descriptive name.
+Branch names are ephemeral:
+When a pull request is merged,
+the merge commit doesn’t include name of your feature branch.
+
+If you need to incorporate changes from `main` or resolve a merge conflict,
+merge `main` into your feature branch.
+Before creating a pull request,
+you can instead rebase your feature branch onto `main` if you prefer,
+but don't rebase commits that are part of a pull request.
+
+## Writing commit messages
+
+Use the Git commit message to communicate with other contributors —
+both the people working on the project now
+who are reviewing your changes,
+and people who join the project in the future
+who will need to understand what you changed and why.
+
+Every commit starts with a one-sentence summary.
+The summary usually fits in 50 characters,
+but it's ok to exceed that amount occasionally
+if rewriting for brevity would make it too hard to read.
+If it's hard to write a good summary,
+try breaking your changes into multiple smaller commits.
+
+If you can't explain the commit entirely in its summary,
+skip one line and add additional information.
+This additional information includes information like
+the reasons for the change,
+the approach you took when making it,
+alternatives you considered,
+and a summary of what you changed.
+Hard wrap these lines at 72 characters
+and leave a blank line between paragraphs.
+The body of a commit is plain text,
+not markdown like the content of the book.
+
+Following these formatting conventions in your commit
+makes it easier to read
+in places like the output from `git` and notification emails.
+Most text editors can help you write a commit message
+by marking lines that are too long
+and hard wrapping text automatically.
+
+## Submitting a pull request
+
+Use the following steps when creating a new pull request:
+
+1. Test that your changes build locally by running `docc preview TSPL.docc`.
+2. Create a pull request in this repository.
+3. Write a brief message in the pull request to introduce your work in context.
+
+Within a few days,
+someone will assign reviewers and start a build in CI.
+
+During the review of the pull request,
+add new commits on your branch to incorporate feedback,
+but don’t rebase or force push.
+Rewriting the branch's history
+makes it hard for reviewers to see
+what changed since the last time they reviewed your changes.
+If there are merge conflicts,
+merge `main` into your branch or use the GitHub web UI
+to resolve the conflicts when accepting the pull request.
+
+After a pull request is merged, delete the feature branch.