https://github.com/apple/swift-evolution/blob/master/proposa...
https://github.com/apple/swift-evolution/blob/master/proposa...
I've heard many people on the mailing lists talk about wanting to add hygienic macros–so when you're talking about "full-fledged macros", are you talking about unhygienic or hygienic ones?
> See Joe Groff's talk for details
I'm actually curious how much is possible, in terms of reflection capability, both currently and in the future. How close can I get to the dynamism of say the Objective-C runtime? Can I grab a function pointer knowing its mangled name? Can I list every class in a binary by consulting the runtime metadata? Can I "swizzle"?
Well, right now the compiler emits a lot of metadata that is mostly used for runtime generics, dynamic casting, and the (somewhat limited) Mirror type. But these features have enough generality that a surprising amount of stuff has to be encoded. However there’s no nice API for looking at it yet.
> Can I grab a function pointer knowing its mangled name?
That’s just dlsym().
> Can I list every class in a binary by consulting the runtime metadata?
The metadata is there, but there’s no exposed API for doing this.
> Can I "swizzle"?
There’s an experimental thing for this now: https://github.com/apple/swift/pull/20333
> That’s just dlsym().
Sorry, I should have been more clear: can I grab a function pointer to an unexported function?
> > Can I "swizzle"?
> There’s an experimental thing for this now: https://github.com/apple/swift/pull/20333
This is interesting; I haven't been really been following the lists recently but I took the time to read the linked thread and the pull request. While the functionality contained in the pull request is interesting, it's not quite the same as swizzling since it's done unconditionally at load time rather than runtime (so it's much more similar to DYLD_INTERPOSE in that sense). While this covers many of the cases when swizzling is necessary, it leaves out a rather important one where the correct method override is selected at runtime, generally conditionally.
Also, as a sidenote, it seems that there is some sort of motivation to have compiler type checks for the replacement, i.e. @_dynamicReplacement(for: bar())–how will this actually work in practice? If I compile a bundle without access to the source of the application I'm going to be loaded into, how would bar() be accessible to the compiler at all?