Swift Opt-In Reflection metadata

[maxovtsin]

A prototype for a swift evolution proposal that implements opt-in reflection metadata.

Proposal - swiftlang/swift-evolution#1203
Discussion - https://forums.swift.org/t/pitch-2-opt-in-reflection-metadata/41696

[jckarter]

Protocols should never emit field descriptors because they aren't types by themselves and never have fields. It looks like an oversight that these get emitted in the first place and hopefully nothing will break if we stop emitting them because they're always empty.

[jckarter]

@Azoy points out that it isn't even possible to find these field descriptors from the protocol descriptor, so yeah, they're probably unused.

[maxovtsin]

Is it possible that those symbols are used by the debugger? I tried to stop emitting field descriptor for protocols, but several tests started failing (like this one - reflect(object: TestGeneric(D() as P))). Not sure how to check what exactly uses it.

[slavapestov]

Protocol "field descriptors" encode whether the protocol is ObjC or not.

[mikeash]

This is really neat! I like how you handle conditional casting to the marker protocol. Does this handle casting to protocol compositions including Reflectable, like as? P & Q & Reflectable? I'm not quite sure what sort of code the compiler would emit for that.

[maxovtsin]

This is really neat! I like how you handle conditional casting to the marker protocol. Does this handle casting to protocol compositions including Reflectable, like as? P & Q & Reflectable? I'm not quite sure what sort of code the compiler would emit for that.

Good catch, thanks!
(Fixed by allowing casts to protocol composition types with Reflectable)

[hoangatuan]

Almost 4 years for this MR..
I think this is really cool and can reduce app size a lot

[slavapestov]

I think instead of adding a new layout constraint (which as you saw requires a lot of new plumbing) this could instead use a marker protocol?

[maxovtsin]

@slavapestov I used a marker protocol in the first iteration of the implementation to make the logic simpler, but the first review feedback made it clear that marker protocols shouldn't affect runtime behaviour therefore it was suggested to create a new non-protocol generic constraint similar to AnyObject, which requires to handle many cases in the code. 🤷

https://forums.swift.org/t/returned-for-revision-se-0379-opt-in-reflection-metadata/62390

[slavapestov]

In the year since that was written, Copyable, Escapable and BitwiseCopyable were added as marker protocols. I understand the frustration here in going back and forth, but I really think modeling these kinds of relations as conformances makes the most sense, and in hindsight I sometimes wish AnyObject didn't exist as a special case either. CC @jckarter