Beta 2.094.0

[FeepingCreature]

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.