Beta 2.094.0

DlangUser38 DlangUser at
Sun Sep 13 18:33:50 UTC 2020

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 "".
> 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.
> -Steve

Imports need to be fully qualified in the resulting tuple.

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".

More information about the Digitalmars-d-announce mailing list