September 13, 2020
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
September 13, 2020
On Sunday, 13 September 2020 at 19:16:24 UTC, Steven Schveighoffer wrote:
> On 9/13/20 2:33 PM, DlangUser38 wrote:
>> [...]
>
> 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.
>
>> [...]
>
> 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'm not sure if I react exactly to your answer but I agree that getMember should have a counter part. This point was not raised during the review. Previously getMember worked but you could just do nothing with the "std" when it was for "std.stdio".
September 13, 2020
On Sunday, 13 September 2020 at 14:52:13 UTC, MrSmith wrote:
> On Friday, 11 September 2020 at 07:48:00 UTC, Martin Nowak wrote:
>> Glad to announce the first beta for the 2.094.0 release, ♥ to the 49 contributors.
>>
>> This is the first release to be built with LDC on all platforms, so we'd welcome some more thorough beta testing.
>>
>> http://dlang.org/download.html#dmd_beta
>> http://dlang.org/changelog/2.094.0.html
>>
>> As usual please report any bugs at
>> https://issues.dlang.org
>>
>> -Martin
>
> One unfortunate sideeffect of allMembers change is that it breaks this king of loop:
> ```
> foreach(m; __traits(allMembers, M)) { // M is module
>     alias member = __traits(getMember, M, m); // now fails because std.stdio is not a member of M
> }
> ```
>
> To fix I needed to rewrite it as:
> ```
> foreach(m; __traits(allMembers, M)) { // M is module
>     static if (__traits(compiles, __traits(getMember, M, m)))
>         alias member = __traits(getMember, M, m);
> }
> ```

https://github.com/dlang/dmd/pull/11727

Note that previously you could do nothing with the partial alias, eg "std" instead of "std.stdio". Now that the fully qualified name is returned, and with the pending fixup
this works:

---
module m;

import std.stdio;

void main()
{
    alias s = __traits(getMember, m, "std.stdio");
    s.writeln("mmh");
    static assert(__traits(hasMember, m, "std.stdio"));
}
---

Anyway, thnaks for poiting out the problem. You were right, getMember had to work with anything that's returned by allMember. There nothing to discuss about that.
September 14, 2020
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.
September 14, 2020
On Friday, 11 September 2020 at 07:48:00 UTC, Martin Nowak wrote:
> Glad to announce the first beta for the 2.094.0 release, ♥ to the 49 contributors.
>
> This is the first release to be built with LDC on all platforms, so we'd welcome some more thorough beta testing.
>
> http://dlang.org/download.html#dmd_beta
> http://dlang.org/changelog/2.094.0.html
>
> As usual please report any bugs at
> https://issues.dlang.org
>
> -Martin

Nice!
September 14, 2020
On Sunday, 13 September 2020 at 16:33:42 UTC, James Blachly wrote:
> {
>     "name": "git-dependency",
>     "dependencies": {
>         "gitcompatibledubpackage": {
>             "repository": "git+https://github.com/dlang-community/gitcompatibledubpackage.git",
>             "version": "ccb31bf6a655437176ec02e04c2305a8c7c90d67"
>         }
>     }
> }


On a git repo, where to get this version string?

BTW, pass in "master" does not work.
September 14, 2020
On 9/14/20 5:17 PM, mw wrote:
> On Sunday, 13 September 2020 at 16:33:42 UTC, James Blachly wrote:
>> {
>>     "name": "git-dependency",
>>     "dependencies": {
>>         "gitcompatibledubpackage": {
>>             "repository": "git+https://github.com/dlang-community/gitcompatibledubpackage.git",
>>             "version": "ccb31bf6a655437176ec02e04c2305a8c7c90d67"
>>         }
>>     }
>> }
> 
> 
> On a git repo, where to get this version string?
> 
> BTW, pass in "master" does not work.

Looks like the commit hash ; use `git log`

Agree a branch name would be nice , then it could automatically take HEAD

September 15, 2020
On Saturday, 12 September 2020 at 13:09:55 UTC, Per Nordlöw wrote:
> Where can I update the changelog to include this?

https://github.com/dlang/dmd/pull/11732
September 15, 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.
>

We should have the ability to get compiler tuple with the actual symbols.
allMembers within type functions works that way as well, within a type functions you don't get strings but references to the actual things.
We should do this with a separate __trait though.
Perhaps __traits(getMembers) ?
September 16, 2020
On Monday, 14 September 2020 at 23:36:45 UTC, James Blachly wrote:
> On 9/14/20 5:17 PM, mw wrote:
>> On Sunday, 13 September 2020 at 16:33:42 UTC, James Blachly wrote:
>>> {
>>>     "name": "git-dependency",
>>>     "dependencies": {
>>>         "gitcompatibledubpackage": {
>>>             "repository": "git+https://github.com/dlang-community/gitcompatibledubpackage.git",
>>>             "version": "ccb31bf6a655437176ec02e04c2305a8c7c90d67"
>>>         }
>>>     }
>>> }
>> 
>> 
>> On a git repo, where to get this version string?
>> 
>> BTW, pass in "master" does not work.
>
> Looks like the commit hash ; use `git log`
>
> Agree a branch name would be nice , then it could automatically take HEAD


Actually I just saw this:

https://dub.pm/package-format-json#version-specs

-- Use a GIT branch (deprecated): "~master"


Why it's deprecated? can we revive it?