feepingcreature at gmail.com
Mon Sep 14 07:54:49 UTC 2020
On Sunday, 13 September 2020 at 19:16:24 UTC, Steven
> 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.
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.
More information about the Digitalmars-d-announce