On 9/13/20 2:33 PM, DlangUser38 wrote:
On Sunday, 13 September 2020 at 17:51:49 UTC, Steven Schveighoffer wrote:
On 9/13/20 1:25 PM, MrSmith wrote:
On Sunday, 13 September 2020 at 15:12:00 UTC, Steven Schveighoffer
wrote:
The first part of the change seems disruptive. If you just fix the
second part (that you can now retrieve all members of std), doesn't
it fix the problem?
Main problem is that allMembers returns strings and you can't tell if
member is an import from it. If it returned aliases then you could do
is(m == module), etc.
It's always been string, and should always be.
But I don't know of another case where it returns something that can't
be passed to getMember. You should be able to use getMember on "std",
and then getMember on that with "stdio". Just like any other nested
thing.
It would be just as confusing as if you had:
struct S
{
int foo;
}
and __traits(allMembers, mod) contained "S.foo".
BTW, when I wrote that first response, I didn't realize that
__traits(allMembers, std) returns... a lot of stuff. the whole
mechanism seems like it doesn't do what I would expect.
Imports need to be fully qualified in the resulting tuple.
I can't think of any other case where getting allMembers returns
something other than an Identifier. It's super surprising that something
returned by allMembers is not actually a member of the thing you got it
from.
Arguably, NO imports that aren't renamed or aliased should be included
in the members.
having `import std.stdio;` and just "std" in the tuple was a bug. I mean
this is not an opinion it worked like that by error, the special case
for imports was not considered so "std" slipped in the result while it
should always have been "std.stdio".
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
