Beta 2.094.0

[Steven Schveighoffer]

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