Closed timholy closed 3 years ago
Hi Tim, thank you for the PR. I merged, but I must admit that I don't get it, I'm out of the loop...
This avoids invalidations of in or == for Symbols.
I understand how your PR makes this function more inferrable, but I don't understand how it affects invalidations. Isn't isor
meant to be used in macro code, where inferrability / performance is really not a big concern usually. Will I get it after watching https://www.youtube.com/watch?v=rVBgrWYKLHY ?
Yes, this is directed at latency reduction, but that's probably not the best choice of video. Instead you might read https://julialang.org/blog/2020/08/invalidations/ or watch https://www.youtube.com/watch?v=7VbXbI6OmYo. What this PR does is limit the "damage" for any package that uses MacroTools if one later loads another package that specializes in
or ==
. The problem here is that the call to in
(which ultimately calls ==
) is not inferrable, and thus this macro introduces vulnerability to being invalidated.
This avoids invalidations of
in
or==
for Symbols.There are several other inferrability issues with this package,
unblock
being a real champion source, which may essentially be unfixable. Consequently users of this package may have to be prepared for a certain amount of precompile failures.CC @ChrisRackauckas.