SE-0379 - Opt-In Reflection Metadata Implementation

Development Compiler
1

Hello everyone!
I'd like to resume work and start implementation discussion on the SE-0379 proposal, whose first version was reviewed and sent back for revision.

Changing the default behavior of reflection generation

The concerns raised were fair and make sense. Therefore, I agree that it would be best not to change the compiler’s default behavior while introducing a new mode that allows developers to explicitly enable opt-in reflection when size or security concerns arise.

Debugger support

One option, which was discussed in a previous thread, is to emit two separate copies of the reflection metadata into distinct sections.

  • The old section would contain only runtime metadata (either full or opt-in).
  • The new section would include full debug information, intended exclusively for LLDB.

Additionally, dsymutil would be updated to ignore the old section while cloning the new one into the dSYM bundle. I believe this approach would effectively address the concerns raised during the review.

The nature of Reflectable, and dynamic casting support

The biggest challenge I encountered while trying to implement Reflectable as AnyObject is the complexity it introduces in the compiler. While I understand that implementing Reflectable as a non-protocol generic constraint makes sense, the implementation would add significant complexity to the compiler's code and could introduce potential bugs.

At this point, I see two feasible approaches:

  1. Keep Reflectable as a marker protocol, as suggested by @Slava_Pestov in this discussion.
  2. Introduce a new protocol attribute, such as @_compilerKnown. This would allow Sema to handle type checking and enforce generic constraints automatically (unlike AnyObject, for example), while ensuring that protocols marked with this attribute do not generate any protocol-related runtime metadata.
@_compilerKnown
protocol Reflectable {}

What do you think?

cc @John_McCall @Slava_Pestov @Joe_Groff

1 Like