Fix inaccuracies

Author: aryan-25

Sources/AWSLambdaRuntimeCore/Documentation.docc/Proposals/0001-v2-api.md

@@ -18,7 +18,7 @@ running blocking code on the same `EventLoop` the library uses. Developers also
 methods that are used to work with `EventLoop`s and `EventLoopFuture`s. This results in a lot of cognitive complexity
 and makes the code in the current API hard to reason about and maintain. For these reasons, the overarching trend in the
 Swift on Server ecosystem is to shift to newer, more readable, Swift concurrency constructs and de-couple from
-SwiftNIO’s `EventLoop` interfaces.
+SwiftNIO's `EventLoop` interfaces.
 
 #### No ownership of the main() function
 
@@ -37,13 +37,13 @@ an implementation of the `handle` function where the business logic of the Lambd
 `SimpleLambdaHandler` is perfectly sufficient for small use-cases as the user does not need to spend much time looking
 into the library.
 
-However, `SimpleLambdaHandler` cannot be used when services such as a database client need to be initalized before the
+However, `SimpleLambdaHandler` cannot be used when services such as a database client need to be initialized before the
 Lambda runtime starts and then also gracefully shutdown prior to the runtime terminating. This is because the only way
 to register termination logic is through the `LambdaInitializationContext` (containing a field
 `terminator: LambdaTerminator`) which is created and used _internally_ within `LambdaRuntime` and never exposed through
 `SimpleLambdaHandler`. For such use-cases, other handler protocols like `LambdaHandler` must be used. `LambdaHandler`
 exposes a `context` argument of type `LambdaInitializationContext` through its initializer. Within the initializer,
-required services can be initalized and their graceful shutdown logic can be registered with the
+required services can be initialized and their graceful shutdown logic can be registered with the
 `context.terminator.register` function.
 
 Yet, `LambdaHandler` is quite cumbersome to use in such use-cases as users have to deviate from the established norms of
@@ -57,7 +57,7 @@ The Lambda runtime can only be started using the **internal** `Lambda.run()` fun
 `main()` function defined by the `LambdaHandler` protocol, preventing users from injecting initialized services into the
 runtime _prior_ to it starting. As shown below, this forces users to use an **unstructured concurrency** approach and
 manually initialize services, leading to the issue of the user then perhaps forgetting to gracefully shutdown the
-initalized services:
+initialized services:
 
 ```swift
 struct MyLambda: LambdaHandler {
@@ -88,7 +88,7 @@ struct MyLambda: LambdaHandler {
     }
 
     func handle(_ event: Event, context: LambdaContext) async throws -> Output {
-        /// Use the initalized service stored in `self.pgClient`
+        /// Use the initialized service stored in `self.pgClient`
         try await self.pgClient.query(...)
     }
 }
@@ -131,7 +131,7 @@ of the `EventLoop` family of interfaces.
   same way the lifecycles of the required services are managed, e.g.
   `try await ServiceGroup(services: [postgresClient, ..., lambdaRuntime], ...).run()`.
 - Dependencies can now be injected into `LambdaRuntime` — `swift-service-lifecycle` guarantees that the services will be
-  initialized _before_ the `LambdaRuntime`’s `run()` function is called.
+  initialized _before_ the `LambdaRuntime`'s `run()` function is called.
 - The required services can then be used within the handler in a structured concurrency manner.
   `swift-service-lifecycle` takes care of listening for termination signals and terminating the services as well as the
   `LambdaRuntime` in correct order.
@@ -162,7 +162,7 @@ try await serviceGroup.run()
 
 ### Simplifying Codable support
 
-A detailed explanation is provided in the Codable Support section. In short, much of the boilerplate code defined for
+A detailed explanation is provided in the **Codable Support** section. In short, much of the boilerplate code defined for
 each handler protocol in `Lambda+Codable` and `Lambda+String` will be replaced with a single `LambdaCodableAdapter`
 class.
 
@@ -181,7 +181,7 @@ Both will be explained in the **Detailed Solution** section.
 
 ## Detailed Solution
 
-Below you’ll find explanation’s for all types that we want to use in AWS Lambda Runtime v2.
+Below are explanations for all types that we want to use in AWS Lambda Runtime v2.
 
 ### LambdaResponseWriter
 
@@ -205,10 +205,10 @@ public protocol LambdaResponseWriter: ~Copyable {
 ### LambdaContext
 
 `LambdaContext` will be largely unchanged, but the `eventLoop` property as well as the `allocator` property (of type
-`ByteBuffer`) will be removed.
+`ByteBufferAllocator`) will be removed.
 
-A new function `backgroundTask()` will also be added. This will allow tasks to be run in the background while and after
-the response is/has been sent. Please note that `LambdaContext` will not be Sendable anymore.
+A new function `addBackgroundTask(_:)` will also be added. This will allow tasks to be run in the background while and after
+the response is/has been sent. Please note that `LambdaContext` will not be `Sendable` anymore.
 
 ```swift
 /// A context object passed as part of an invocation in LambdaHandler handle functions.
@@ -247,10 +247,10 @@ public struct LambdaContext {
 ### StreamingLambdaHandler
 
 The new `StreamingLambdaHandler` protocol is the base protocol to implement a Lambda function. Most users will not use
-this protocol and instead use the `LambdaHandler` protocol defined in the `Codable` Support section.
+this protocol and instead use the `LambdaHandler` protocol defined in the **Codable Support** section.
 
 ```swift
-/// The base LambdaHandler protocol
+/// The base StreamingLambdaHandler protocol
 public protocol StreamingLambdaHandler: ~Copyable {
     /// The business logic of the Lambda function
     /// - Parameters:
@@ -354,7 +354,7 @@ enum Lambda {
 Since the library now provides ownership of the `main()` function and allows users to initialize services before the
 `LambdaRuntime` is initialized, the library cannot implicitly report
 [errors that occur during initialization to the dedicated endpoint AWS exposes](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.html#runtimes-api-initerror)
-like it currently does through the `initialize()` function of `LambdaRunner` which wraps the handler’s `init(...)` and
+like it currently does through the `initialize()` function of `LambdaRunner` which wraps the handler's `init(...)` and
 handles any errors thrown by reporting it to the dedicated AWS endpoint.
 
 To retain support for initialization error reporting, the `Lambda.reportStartupError(any Error)` function gives users
@@ -431,7 +431,7 @@ public protocol LambdaOutputEncoder {
 }
 ```
 
-We provide conformances for Foundation’s `JSONDecoder` to `LambdaEventDecoder` and `JSONEncoder` to
+We provide conformances for Foundation's `JSONDecoder` to `LambdaEventDecoder` and `JSONEncoder` to
 `LambdaOutputEncoder`.
 
 3. Implements its `handle()` method by:
@@ -446,7 +446,7 @@ We provide conformances for Foundation’s `JSONDecoder` to `LambdaEventDecoder`
 the user.
 
 ```swift
-/// Wraps an underlying handler conforming to `CodableLambdaHandler`
+/// Wraps an underlying handler conforming to `LambdaHandler`
 /// with encoding/decoding logic
 public struct LambdaCodableAdapter<
     Handler: LambdaHandler,
@@ -486,16 +486,16 @@ To create a Lambda function using the current API, a user first has to create an
 handler protocols by implementing the initializer and the `handle(...)` function. Now that `LambdaRuntime` is public,
 this verbosity can very easily be simplified.
 
-**ClosureHandler**
+#### ClosureHandler
 
 This handler is generic over any `Event` type conforming to `Decodable` and any `Output` type conforming to `Encodable`
 or `Void`.
 
 ```swift
 public struct ClosureHandler<Event, Output>: LambdaHandler {
-    /// Intialize with a closure handler over generic Input and Output types
+    /// Initialize with a closure handler over generic Input and Output types
     public init(body: @escaping (Event, LambdaContext) async throws -> Output) where Output: Encoda
-    /// Intialize with a closure handler over a generic Input type (Void Output).
+    /// Initialize with a closure handler over a generic Input type (Void Output).
     public init(body: @escaping (Event, LambdaContext) async throws -> Void) where Output == Void
     /// The business logic of the Lambda function.
     public func handle(_ event: Event, context: LambdaContext) async throws -> Output
@@ -523,7 +523,7 @@ extension LambdaRuntime {
 }
 ```
 
-We can now significantly reduce the verbosity and leverage Swift’s trailing closure syntax to cleanly create and run a
+We can now significantly reduce the verbosity and leverage Swift's trailing closure syntax to cleanly create and run a
 Lambda function, abstracting away the decoding and encoding logic from the user:
 
 ```swift
@@ -643,8 +643,8 @@ parameter has benefits as the lifetime of the handle function is tied to the inv
 returns a `LambdaResponse` splits the invocation into two separate function calls. First the handle method is invoked,
 second the `LambdaResponse` writer closure is invoked. This means that it is impossible to use Swift APIs that use
 `with` style lifecycle management patterns from before creating the response until sending the full response stream off.
-This means for example: That users instrumenting their lambdas with Swift tracing likely can not use the `withSpan` API
-for the full lifetime of the request, if they return a streamed response.
+For example, users instrumenting their lambdas with Swift tracing likely can not use the `withSpan` API for the full
+lifetime of the request, if they return a streamed response.
 
 However, if it comes to consistency with the larger Swift on server ecosystem, the API that returns a `LambdaResponse`
 is likely the better choice. Hummingbird v2, OpenAPI and the new Swift gRPC v2 implementation all use this approach.
@@ -658,6 +658,6 @@ We welcome the discussion on this topic and are open to change our minds and API
 ## A word about versioning
 
 We are aware that AWS Lambda Runtime has not reached a proper 1.0. We intend to keep the current implementation around
-at 1.0-alpha. We don’t want to change the current API without releasing a new major. We think there are lots of adopters
+at 1.0-alpha. We don't want to change the current API without releasing a new major. We think there are lots of adopters
 out there that depend on the API in v1. Because of this we intend to release the proposed API here as AWS Lambda Runtime
 v2.