1

Given the following code:

struct Thing {
    var name: String { "name" }
}

print(\Thing.name)
print(String(describing: \Thing.name))
print("\(\Thing.name)")

The output on macOS, M1 Pro, Ventura 13.5.2:

\Thing.name
\Thing.name
\Thing.name

Toolchain: Apple Swift version 5.9-dev (LLVM f8c4926c34d7084, Swift 2961cafb053b11d) Target: arm64-apple-macosx13.0

The output inside an aarch64 Linux Docker container:

\Thing.<computed 0x0000aaaadcc91398 (String)>
\Thing.<computed 0x0000aaaadcc91398 (String)>
\Thing.<computed 0x0000aaaadcc91398 (String)>

Toolchain: Swift version 5.9-dev (LLVM f8c4926c34d7084, Swift 2961cafb053b11d) Target: aarch64-unknown-linux-gnu

Question: Is this intended behavior? Is it something that could ever change?

2 Likes
2

Key paths don't directly store any information about property names, and the implementation of description only makes a best effort using symbol names from the executable if available to try to recover a name for logging/diagnostic purposes. If you need the name for load-bearing program logic you'll need to get it by other means.

3 Likes
3

Makes sense.
Do you know if there is any expectation/future possibility of a more robust mechanism for the recovery of field names from KeyPaths to be implemented (whether by storing that information on the KeyPath or otherwise)?

EDIT: https://forums.swift.org/t/introspection-of-keypaths/36879/20 may be the answer to my own question.