How Swift’s Mirror Works

[ingve]

https://swift.org/blog/how-mirror-works/

[maccio92]

C#'s implementation is much more impressive, through the reflection libraries, doesn't require unsafe code, is not a hidden implementation deal, and has a much cleaner interface. Also look into expressions and the awesome things you can do with the framework. Yeah yeah blah blah Microsoft, but that was the company of the past. New leadership has been focused on better things, open sourcing the Roslyn compiler and dotnet core. The c# of 2018 is a brand new beast

[nielsbot → maccio92]

What do you mean? Swift `Mirror` doesn't require unsafe code and is not a hidden implementation detail.

[coldtea → nielsbot]

>Swift `Mirror` doesn't require unsafe code and is not a hidden 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.

[nielsbot → coldtea]

But that's not visible to the clients of `Mirror` API. Inside Swift `Mirror` is just another high-level API.

[sedatk → nielsbot]

That’s what the article says:

> Everything here is an internal implementation detail.

[tinus_hn → sedatk]

The way it works is an implementation detail, the fact that it does is not.

[lostmsu → maccio92]

I am pretty sure System.Type is partially implemented via unsafe code. The wrapper is managed, but so is the Swift's.

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?

[slavapestov → lostmsu]

> 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?

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.

[zamalek → lostmsu]

> I am pretty sure System.Type is partially implemented via unsafe code.

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.