Can't suppress retroactive conformance by fully qualifying with module names within the same line

Using Swift
, , ,
1

I'm trying to mute the retroactive conformance of external types warning ( SE-0364) by "Fully qualify the names of the type and the protocol with module names (to acknowledge the risks)." (from this post)

import _CryptoExtras
import Crypto
import Foundation

public protocol SecKeyx963Convertible: CustomStringConvertible {}

extension SecKeyx963Convertible {
  public var description: String { "hello"}
}

// Warning: 
// Extension declares a conformance of imported type 'PublicKey' to imported protocol 'CustomStringConvertible';
// this will not behave correctly if the owners of 'CryptoKit' introduce this conformance in the future
extension P256.Signing.PublicKey: SecKeyx963Convertible, Swift.CustomStringConvertible {}

// This is fine
//extension P256.Signing.PublicKey: SecKeyx963Convertible {}
//extension P256.Signing.PublicKey: Swift.CustomStringConvertible {}

I just feel strange why putting these two conformance in two separate lines can mute the conformance of imported type warning, but not when I put them into the same line?

I'm using Xcode 16 Beta 2

Package.swift for anyone wants to reproduce:

// swift-tools-version: 5.9.0
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription
import CompilerPluginSupport

let package = Package(
    name: "Untitled",
    platforms: [
      .macOS(.v14)
    ],
    dependencies: [
      .package(url: "https://github.com/apple/swift-crypto/", exact: "2.0.3"),
    ],
    targets: [
        // Targets are the basic building blocks of a package, defining a module or a test suite.
        // Targets can depend on other targets in this package and products from dependencies.
      .executableTarget(
          name: "Untitled",
          dependencies: [
            .product(name: "_CryptoExtras", package: "swift-crypto"),
          ]
        )
    ],
    swiftLanguageVersions: [.v5]
)
2

Sounds like this could be simply an oversight—worth filing a bug on GitHub!

3 Likes
3

Also even acknowledging the risks, please do not do this.

3 Likes
4

Also even acknowledging the risks, please do not do this.

I guess for CustomStringConvertible this is probably fine? Like this is only a string which shouldn't do much harm. But still want to know is there any particular reason for this not being a good idea?

5

Retroactive conformances are never a good idea. @jrose has written what I think are the canonical pair of articles on the topic.

Even for CustomStringConvertible, this is not fine. I might go further and say that especially for CustomStringConvertible this is not fine, as the only purpose of a CustomStringConvertible conformance is to enable nicer print statements, and in your code you can get those by printing something else.

4 Likes
6

Yeah, knowingly extending a cryptography type so that it can have arbitrary string conversion behavior is super duper not fine.

2 Likes