Upstream Repository Updated with Detailed Diff

[github-actions]

The upstream repository https://github.com/swiftlang/swift-book has new commits.

Detailed changes (showing up to 1000 lines):

diff --git a/Style.md b/Style.md
index 2a77bbf1..721c0b81 100644
--- a/Style.md
+++ b/Style.md
@@ -313,6 +313,25 @@ when it‘s the actual agent performing the action.
 We don’t distinguish between the parts of the compiler
 like the parser or the lexer or the optimizer.
 
+## upcoming features
+
+Starting with the implementation of
+[SE-0362: Piecemeal adoption of upcoming language improvements][SE-0362],
+some language features are available on an opt-in basis
+before being enabled by default.
+
+At the beginning of a section or chapter about a future feature,
+include a note as follows.
+
+> Note:
+> This language feature will be part of Swift *n*.
+> To enable it in current versions of Swift,
+> use the feature identifier `SomeFeatureIdentifier`.
+> For information about enabling future language features,
+> see [Enabling future language features](FIXME).
+
+[SE-0362]: https://github.com/apple/swift-evolution/blob/main/proposals/0362-piecemeal-future-features.md
+
 # Tone
 
 In general, and especially in the guide,
diff --git a/TSPL.docc/GuidedTour/GuidedTour.md b/TSPL.docc/GuidedTour/GuidedTour.md
index fd53dd58..17e00df4 100644
--- a/TSPL.docc/GuidedTour/GuidedTour.md
+++ b/TSPL.docc/GuidedTour/GuidedTour.md
@@ -1624,7 +1624,7 @@ or it responds with a description of what went wrong.
   The server response is a simple way to essentially re-implement Optional
   while sidestepping the fact that I'm doing so.
 
-  "Out of cheese" is a reference to a Terry Pratchet book,
+  "Out of cheese" is a reference to a Terry Pratchett book,
   which features a computer named Hex.
   Hex's other error messages include:
 
diff --git a/TSPL.docc/LanguageGuide/AccessControl.md b/TSPL.docc/LanguageGuide/AccessControl.md
index 817cb688..26dacc8f 100644
--- a/TSPL.docc/LanguageGuide/AccessControl.md
+++ b/TSPL.docc/LanguageGuide/AccessControl.md
@@ -169,61 +169,29 @@ and compile that product module with testing enabled.
 ## Access Control Syntax
 
 Define the access level for an entity by placing
-one of the `open`, `public`, `internal`, `fileprivate`, or `private` modifiers
+one of the modifiers listed in <doc:AccessControl#Access-Levels>,
+such as `public` or `private`,
 at the beginning of the entity's declaration.
+For example:
 
 ```swift
-open class SomeOpenClass {}
 public class SomePublicClass {}
-internal class SomeInternalClass {}
-fileprivate class SomeFilePrivateClass {}
-private class SomePrivateClass {}
-
-open var someOpenVariable = 0
-public var somePublicVariable = 0
-internal let someInternalConstant = 0
-fileprivate func someFilePrivateFunction() {}
+internal struct SomeInternalStruct() {}
 private func somePrivateFunction() {}

-<!--

• • test: accessControlSyntax
• -> open class SomeOpenClass {}
• -> public class SomePublicClass {}
• -> internal class SomeInternalClass {}
• -> fileprivate class SomeFilePrivateClass {}
• -> private class SomePrivateClass {}
• -> open var someOpenVariable = 0
• -> public var somePublicVariable = 0
• -> internal let someInternalConstant = 0
• -> fileprivate func someFilePrivateFunction() {}
• -> private func somePrivateFunction() {}

--->

-Unless otherwise specified, the default access level is internal,
+The code above declares SomePublicClass as public,
+SomeInternalStruct as internal,
+and somePrivateFunction() as private.
+If you don't write an explicit access level,
+the default access level modifier is internal,
as described in doc:AccessControl#Default-Access-Levels.
-This means that SomeInternalClass and someInternalConstant can be written
-without an explicit access-level modifier,
-and will still have an access level of internal:
+For example, in the code below, SomeInternalStruct is implicitly internal:

-class SomeInternalClass {}              // implicitly internal
-let someInternalConstant = 0            // implicitly internal
+struct SomeInternalStruct() {}

-<!--

• • test: accessControlDefaulted
• -> class SomeInternalClass {} // implicitly internal
• -> let someInternalConstant = 0 // implicitly internal

--->

Custom Types

If you want to specify an explicit access level for a custom type,
diff --git a/TSPL.docc/LanguageGuide/Concurrency.md b/TSPL.docc/LanguageGuide/Concurrency.md
index 328a3a0c..7c73a17b 100644
--- a/TSPL.docc/LanguageGuide/Concurrency.md
+++ b/TSPL.docc/LanguageGuide/Concurrency.md
@@ -555,7 +555,7 @@ Each task in a given task group has the same parent task,
and each task can have child tasks.
Because of the explicit relationship between tasks and task groups,
this approach is called structured concurrency.
-The explicit parent-child relationships between tasks has several advantages:
+The explicit parent-child relationship between tasks has several advantages:

• In a parent task,
  you can't forget to wait for its child tasks to complete.
  @@ -590,7 +590,7 @@ The code above creates a new task group,
  and then creates child tasks
  to download each photo in the gallery.
  Swift runs as many of these tasks concurrently as conditions allow.
  -As soon a child task finishes downloading a photo,
  +As soon as a child task finishes downloading a photo,
  that photo is displayed.
  There's no guarantee about the order that child tasks complete,
  so the photos from this gallery can be shown in any order.
  @@ -669,7 +669,7 @@ Downloading pictures could take a long time
  if the pictures are large or the network is slow.
  To let the user stop this work,
  without waiting for all of the tasks to complete,
  -the tasks need check for cancellation and stop running if they are canceled.
  +the tasks need to check for cancellation and stop running if they are canceled.
  There are two ways a task can do this:
  by calling the [Task.checkCancellation()][] type method,
  or by reading the [Task.isCancelled][Task.isCancelled type] type property.
  @@ -1092,7 +1092,7 @@ The code above is similar to
  but the code in this example doesn't wait for the UI update.
  You can also write @MainActor on a structure, class, or enumeration
  to ensure all of its methods and all access to its properties
  -to run on the main actor:
  +run on the main actor:

@MainActor
@@ -1106,7 +1106,7 @@ The `PhotoGallery` structure in the code above
draws the photos on screen,
using the names from its `photoNames` property
to determine which photos to display.
-Because `photoNames` effects the UI,
+Because `photoNames` affects the UI,
code that changes it needs to run on the main actor
to serialize that access.

@@ -1369,7 +1369,7 @@ during that period of time.
In the future,
if you try to add concurrent code to this function,
introducing a possible suspension point,
-you'll get compile-time error instead of introducing a bug.
+you'll get a compile-time error instead of introducing a bug.


## Global Actors
@@ -1379,7 +1379,7 @@ An actor can normally have multiple instances,
each of which provides independent isolation.
This is why you declare all of an actor's isolated data
as instance properties of that actor.
-However, because `MainActor` is singleton ---
+However, because `MainActor` is a singleton ---
there is only ever a single instance of this type ---
the type alone is sufficient to identify the actor,
allowing you to mark main-actor isolation using just an attribute.
@@ -1568,12 +1568,15 @@ struct TemperatureReading {
-->

To explicitly mark a type as not being sendable,
-write `~Sendable` after the type:
+write an unavailable conformance to `Sendable`:

```swift
-struct FileDescriptor: ~Sendable {
+struct FileDescriptor {
    let rawValue: Int
}
+
+@available(*, unavailable)
+extension FileDescriptor: Sendable {}

-For more information about
-suppressing an implicit conformance to a protocol,
-see doc:Protocols#Implicit-Conformance-to-a-Protocol.
+You can also use an unavailable conformance
+to suppress implicit conformance to a protocol,
+as discussed in doc:Protocols#Implicit-Conformance-to-a-Protocol.