On Sunday, 13 September 2020 at 19:16:24 UTC, Steven
Schveighoffer wrote:
Yeah, I don't know the intention originally. But I have
definitely done exactly what the thread author stated (used
__traits(getMember) on all the module to look for certain
symbols). So my code would be broken too.
Essentially, when you don't care about imports, they get
ignored even if they were there by error. But when
__traits(getMember) actually fails, now it becomes a problem.
Honestly, I've never used __traits(allMembers, module) to look
for imports. Most likely many people don't, since it doesn't
work how you would ever expect. I'd rather we just got rid of
that part of the output than break code that doesn't care about
imports, but does care about the other things in the module. I
don't want to have to write extra mixins to rule this stuff out.
-Steve
I've tried to do this before and failed due to this bug. If it's
removed, we'd need a whole separate __traits infrastructure in
order to walk imports in a project. Not fun.
I don't think we should let backwards compatibility fix us from
fixing cases where the existing behavior is genuinely broken. And
__traits(allMembers, module) was *really* really broken. Much
better to have allMembers return fields that work with
getMembers, since that's very clearly how they're meant to pair
up, and either ignore modules as "don't have the properties we're
scanning for" or discard them via is() on the resulting symbol.
