Re: Beta 2.094.0

2020-09-13 Thread DlangUser38 via Digitalmars-d-announce

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.


Re: beerconf September!

2020-09-13 Thread aberba via Digitalmars-d-announce
On Saturday, 12 September 2020 at 20:56:37 UTC, Steven 
Schveighoffer wrote:
I wanted to once again give people a good notice for the next 
upcoming beerconf, happening September 26th and 27th. As usual, 
bring your favorite beverage (non alcoholic if you prefer), and 
bring your D topics to discuss with the crew. 3 months and 
running, and each one seems to be more and more fun!


This time, we will try to keep a running tally of things 
discussed, and post back here (this was something asked about 
on slack, and I think it's a good idea).


Will ping again before the call.

Cheers!

-Steve


Nice!


Re: Beta 2.094.0

2020-09-13 Thread DlangUser38 via Digitalmars-d-announce
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".


Re: Beta 2.094.0

2020-09-13 Thread Steven Schveighoffer via Digitalmars-d-announce

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


Re: Beta 2.094.0

2020-09-13 Thread DlangUser38 via Digitalmars-d-announce
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.


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


Re: Beta 2.094.0

2020-09-13 Thread DlangUser38 via Digitalmars-d-announce

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);
}
```


the technic to filter out is:

```
foreach(m; __traits(allMembers, M)) { // M is module
  static if (!is(mixin(m) == module))
static if (!is(mixin(m) == package))
{
  
}
```

BTW this is not a side-effect. This is the desired effect. That 
worked previously because the allmembers tuple was incorrect.


Re: Beta 2.094.0

2020-09-13 Thread Steven Schveighoffer via Digitalmars-d-announce

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.


-Steve


Re: Beta 2.094.0

2020-09-13 Thread MrSmith via Digitalmars-d-announce
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?


-Steve


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.


Re: Beta 2.094.0

2020-09-13 Thread James Blachly via Digitalmars-d-announce

On 9/11/20 3:48 AM, 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



The dub change allowing git repository is HUGE !

This allows us to use a private git repository instead of having to have 
the repo already cloned to a specified path on the filesystem.



{
"name": "git-dependency",
"dependencies": {
"gitcompatibledubpackage": {
"repository": 
"git+https://github.com/dlang-community/gitcompatibledubpackage.git";,

"version": "ccb31bf6a655437176ec02e04c2305a8c7c90d67"
}
}
}


Re: Beta 2.094.0

2020-09-13 Thread Steven Schveighoffer via Digitalmars-d-announce

On 9/13/20 10:52 AM, 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);
}
```


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?


-Steve


Re: Beta 2.094.0

2020-09-13 Thread MrSmith via Digitalmars-d-announce

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);
}
```


Re: Beta 2.094.0

2020-09-13 Thread Iain Buclaw via Digitalmars-d-announce
On Friday, 11 September 2020 at 13:44:02 UTC, Guillaume Piolat 
wrote:


This is an absolutely fantastic release! Thanks to all.


[--snip--]


- stricter __vector conversion


Thanks for the shout out, it's taken years to get it adopted by 
dmd. :-)