Move a big explanatory comment to the main target

Author: grynspan

Sources/Overlays/_Testing_CoreGraphics/Attachments/_AttachableImageWrapper+AttachableWrapper.swift

@@ -14,29 +14,6 @@ private import CoreGraphics
 
 private import UniformTypeIdentifiers
 
-/// ## Why can't images directly conform to Attachable?
-///
-/// Three reasons:
-///
-/// 1. Several image classes are not marked `Sendable`, which means that as far
-///    as Swift is concerned, they cannot be safely passed to Swift Testing's
-///    event handler (primarily because `Event` is `Sendable`.) So we would have
-///    to eagerly serialize them, which is unnecessarily expensive if we know
-///    they're actually concurrency-safe.
-/// 2. We would have no place to store metadata such as the encoding quality
-///    (although in the future we may introduce a "metadata" associated type to
-///    `Attachable` that could store that info.)
-/// 3. `Attachable` has a requirement with `Self` in non-parameter, non-return
-///    position. As far as Swift is concerned, a non-final class cannot satisfy
-///    such a requirement, and all image types we care about are non-final
-///    classes. Thus, the compiler will steadfastly refuse to allow non-final
-///    classes to conform to the `Attachable` protocol. We could get around this
-///    by changing the signature of `withUnsafeBytes()` so that the
-///    generic parameter to `Attachment` is not `Self`, but that would defeat
-///    much of the purpose of making `Attachment` generic in the first place.
-///    (And no, the language does not let us write `where T: Self` anywhere
-///    useful.)
-
 @available(_uttypesAPI, *)
 extension _AttachableImageWrapper: Attachable, AttachableWrapper where Image: AttachableAsImage {
   /// Get the image format to use when encoding an image, substituting a

Sources/Testing/Attachments/Images/AttachableAsImage.swift

@@ -14,6 +14,29 @@
 #error("Platform-specific misconfiguration: support for image attachments requires a platform-specific implementation")
 #endif
 
+/// ## Why can't images directly conform to Attachable?
+///
+/// Three reasons:
+///
+/// 1. Several image classes are not marked `Sendable`, which means that as far
+///    as Swift is concerned, they cannot be safely passed to Swift Testing's
+///    event handler (primarily because `Event` is `Sendable`.) So we would have
+///    to eagerly serialize them, which is unnecessarily expensive if we know
+///    they're actually concurrency-safe.
+/// 2. We would have no place to store metadata such as the encoding quality
+///    (although in the future we may introduce a "metadata" associated type to
+///    `Attachable` that could store that info.)
+/// 3. `Attachable` has a requirement with `Self` in non-parameter, non-return
+///    position. As far as Swift is concerned, a non-final class cannot satisfy
+///    such a requirement, and all image types we care about are non-final
+///    classes. Thus, the compiler will steadfastly refuse to allow non-final
+///    classes to conform to the `Attachable` protocol. We could get around this
+///    by changing the signature of `withUnsafeBytes()` so that the
+///    generic parameter to `Attachment` is not `Self`, but that would defeat
+///    much of the purpose of making `Attachment` generic in the first place.
+///    (And no, the language does not let us write `where T: Self` anywhere
+///    useful.)
+
 /// A protocol describing images that can be converted to instances of
 /// [`Attachment`](https://developer.apple.com/documentation/testing/attachment).
 ///