How Swift’s Mirror Works
swift.org
swift.org
> Everything here is an internal implementation detail.
Actually part of the code is C++, so that would be in the unsafe side.
Also they explicitly say that the internals of Mirror are all based on implementation details that might change.
I'd be interested in an overview article about Mirror's features to compare. This article only talks about values. Does it include/support function info? Inheritance? Can it be used to generate code like Reflection.Emit?
Metadata discovery can be done with safe code, it is stored in the PE (on disk). Cecil is a good example of this in action.
Execution of reflected entities is done with runtime intrinsics. Strictly speaking it is unsafe code (as it is written in C/++), but it isn't roped in by any usual means.
Skimming over this article shows that Swift reflection is, effectively, an interface implemented by every object. While the automagic dynamic reflection sounds cool, my alarm bells are ringing because a huge amount of useful tooling needs static bindings. It's one of those cool ideas that is better left unimplemented: it's far more reliable to write a utility library to do this.
The compiler emits some metadata for each class, enum and struct with field types and other information, such as the superclass, protocol conformances, and virtual methods.
The standard library's Mirror type is a thin wrapper around some runtime functions that just lets you introspect the fields of a value. It's pretty limited in what it can do, but there is more metadata there for future use.