www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Beta 2.094.0

reply Martin Nowak <code dawg.eu> writes:
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
Sep 11 2020
next sibling parent reply Guillaume Piolat <firstname.lastname gmail.com> writes:
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


This is an absolutely fantastic release! Thanks to all.
- faster DMD
- dub support of git repositories
- stricter __vector conversion
- throwing in debug block is a convenience feature that will save 
some time
...
Sep 11 2020
next sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Friday, 11 September 2020 at 13:44:02 UTC, Guillaume Piolat 
wrote:

 This is an absolutely fantastic release! Thanks to all.
 - faster DMD



Is this solely thanks to using ldc as host compiler? What are the 
flags passed to ldc when building dmd? Profile guided 
optimization?
Sep 12 2020
prev sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
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. :-)
Sep 13 2020
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
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


Markdown 😎
Sep 11 2020
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On Friday, 11 September 2020 at 07:48:00 UTC, Martin Nowak wrote:

 http://dlang.org/changelog/2.094.0.html

 As usual please report any bugs at
 https://issues.dlang.org

 -Martin


"Equality of arrays of structs is consistent again, as before 
v2.078"

Not a big fan of this. I think it's super dangerous to change 
this behavior again.

Does anyone know when -preview=fieldwise will become the default?
Sep 11 2020
next sibling parent reply kinke <noone nowhere.com> writes:
On Saturday, 12 September 2020 at 00:52:43 UTC, Andrej Mitrovic 
wrote:

 "Equality of arrays of structs is consistent again, as before 
 v2.078"

 Not a big fan of this. I think it's super dangerous to change 
 this behavior again.


Looks like hardly anyone is affected, as the quite obviously 
unsound breaking change in semantics would have been detected and 
fixed way earlier in that case.


 Does anyone know when -preview=fieldwise will become the 
 default?


FWIW, druntime and Phobos are compiled with it since v2.094.
Sep 12 2020
parent reply MoonlightSentinel <moonlightsentinel disroot.org> writes:
On Saturday, 12 September 2020 at 09:07:18 UTC, kinke wrote:

 On Saturday, 12 September 2020 at 00:52:43 UTC, Andrej Mitrovic

 Does anyone know when -preview=fieldwise will become the 
 default?


 FWIW, druntime and Phobos are compiled with it since v2.094.


I think you mean -preview=dtorfields, not fieldwise.
Sep 12 2020
parent kinke <noone nowhere.com> writes:
On Saturday, 12 September 2020 at 11:36:42 UTC, MoonlightSentinel 
wrote:

 On Saturday, 12 September 2020 at 09:07:18 UTC, kinke wrote:

 On Saturday, 12 September 2020 at 00:52:43 UTC, Andrej Mitrovic

 Does anyone know when -preview=fieldwise will become the 
 default?


 FWIW, druntime and Phobos are compiled with it since v2.094.


 I think you mean -preview=dtorfields, not fieldwise.


Absolutely, thx for the correction.
Sep 12 2020
prev sibling parent reply MoonlightSentinel <moonlightsentinel disroot.org> writes:
On Saturday, 12 September 2020 at 00:52:43 UTC, Andrej Mitrovic 
wrote:

 Does anyone know when -preview=fieldwise will become the 
 default?


Currently looking into enabling it by default but it showed an 
interesting side effect. The frontend can now conclude that a == 
b is always true if a and b are instances of an empty struct 
(without custom opEquals).

This caused "unreachable code" warnings for VariantN in Phobos 
and could probably affect other projects as well.
Sep 12 2020
parent reply Paul Backus <snarwin gmail.com> writes:
On Saturday, 12 September 2020 at 11:43:03 UTC, MoonlightSentinel 
wrote:

 Currently looking into enabling it by default but it showed an 
 interesting side effect. The frontend can now conclude that a 
 == b is always true if a and b are instances of an empty struct 
 (without custom opEquals).

 This caused "unreachable code" warnings for VariantN in Phobos 
 and could probably affect other projects as well.


How many improvements does this warning have to block before we 
decide its value for the language is net-negative?

GCC doesn't have it. [1] Clang has it, but only if you 
specifically ask for it with -Wunreachable-code; it's not part of 
-Wall or -Wextra. [2] Rust has it, but lets you turn it off with 
an annotation. [3] Java has it, but it explicitly does *not* take 
constant-folding into account. [4]



each concrete type like D's templates do.

[1] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
[2] 
https://clang.llvm.org/docs/DiagnosticsReference.html#wunreachable-code
[3] 
https://doc.rust-lang.org/rust-by-example/attribute/unused.html
[4] 
https://docs.oracle.com/javase/specs/jls/se14/html/jls-14.html#jls-14.22
[5] https://docs.microsoft.com/en-us/dotnet/csharp/misc/cs0162
Sep 12 2020
next sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Saturday, 12 September 2020 at 13:03:29 UTC, Paul Backus wrote:

 On Saturday, 12 September 2020 at 11:43:03 UTC, 
 MoonlightSentinel wrote:

 Currently looking into enabling it by default but it showed an 
 interesting side effect. The frontend




Attribute would be nice. Then such tagged exceptions can be 
searched for and maybe fixed later.
Sep 12 2020
prev sibling parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Saturday, 12 September 2020 at 13:03:29 UTC, Paul Backus wrote:

 How many improvements does this warning have to block before we 
 decide its value for the language is net-negative?


There's also the option of improving the diagnostic of 
unreachable code.
Sep 12 2020
parent reply Paul Backus <snarwin gmail.com> writes:
On Saturday, 12 September 2020 at 13:40:34 UTC, Per Nordlöw wrote:

 On Saturday, 12 September 2020 at 13:03:29 UTC, Paul Backus 
 wrote:

 How many improvements does this warning have to block before 
 we decide its value for the language is net-negative?


 There's also the option of improving the diagnostic of 
 unreachable code.


Is there? Issue 14835 was reported in 2015. If nobody's been able 
to come up with an improvement in 5 years, what are the odds that 
this year will be the one that lets us finally crack it?

Genuine question, by the way. If it's just an issue of "nobody's 
had time to work on it," then there may be nothing to worry about.
Sep 12 2020
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Saturday, 12 September 2020 at 14:05:04 UTC, Paul Backus wrote:

 Is there? Issue 14835 was reported in 2015. If nobody's been 
 able to come up with an improvement in 5 years, what are the 
 odds that this year will be the one that lets us finally crack 
 it?


I agree, this is unfortunate. Did you read Andreis comment at the 
bottom for the Bugzilla issue?


 Genuine question, by the way. If it's just an issue of 
 "nobody's had time to work on it," then there may be nothing to 
 worry about.


I guess I need to look at the code in dmd. I'm guessing it's a 
long function with lots of state as Walter alluded to in a DConf 
talk.
Sep 12 2020
parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Saturday, 12 September 2020 at 16:54:49 UTC, Per Nordlöw wrote:

 I agree, this is unfortunate. Did you read Andreis comment at 
 the bottom for the Bugzilla issue?


Here https://issues.dlang.org/show_bug.cgi?id=14835#c10
Sep 12 2020
prev sibling next sibling parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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.


I forgot too add the new formatting of -vtemplates to the 
changelog. Shall I?
Sep 12 2020
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Saturday, 12 September 2020 at 11:03:09 UTC, Per Nordlöw wrote:

 I forgot too add the new formatting of -vtemplates to the 
 changelog.


https://github.com/dlang/dmd/pull/11463
Sep 12 2020
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Saturday, 12 September 2020 at 11:43:41 UTC, Per Nordlöw wrote:

 I forgot too add the new formatting of -vtemplates to the 
 changelog.


Where can I update the changelog to include this?
Sep 12 2020
parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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
Sep 15 2020
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On Fri, Sep 11, 2020 at 5:50 PM Martin Nowak via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:


 Glad to announce the first beta for the 2.094.0 release, =E2=99=A5 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



What a monster release! We haven't had one like this for a while!
Sep 12 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/12/2020 5:26 PM, Manu wrote:

 What a monster release! We haven't had one like this for a while!


Should be something for everyone in it :-)
Sep 12 2020
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/11/2020 12:48 AM, Martin Nowak wrote:

 As usual please report any bugs at
 https://issues.dlang.org


https://issues.dlang.org/show_bug.cgi?id=21241

(The changelog is basically illegible on Chrome.)
Sep 12 2020
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/11/2020 12: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
 


Thanks, Martin!

Looks like 9 DMD regressions fixed and 69 DMD bugs fixed!

(It's hard to tell because the changelog won't render properly on Chrome.)
Sep 12 2020
prev sibling next sibling parent reply MrSmith <mrsmith33 yandex.ru> writes:
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);
}
```
Sep 13 2020
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
Sep 13 2020
parent reply MrSmith <mrsmith33 yandex.ru> writes:
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.
Sep 13 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
Sep 13 2020
next sibling parent reply DlangUser38 <DlangUser nowhere.ch> writes:
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".
Sep 13 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
Sep 13 2020
next sibling parent DlangUser38 <DlangUser nowhere.ch> writes:
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".
Sep 13 2020
prev sibling parent FeepingCreature <feepingcreature gmail.com> writes:
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.
Sep 14 2020
prev sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
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) ?
Sep 15 2020
prev sibling next sibling parent DlangUser38 <DlangUser nowhere.ch> writes:
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.
Sep 13 2020
prev sibling parent DlangUser38 <DlangUser nowhere.ch> writes:
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.
Sep 13 2020
prev sibling next sibling parent reply James Blachly <james.blachly gmail.com> writes:
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"
         }
     }
}
Sep 13 2020
parent reply mw <mingwu gmail.com> writes:
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.
Sep 14 2020
parent reply James Blachly <james.blachly gmail.com> writes:
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
Sep 14 2020
parent reply mw <mingwu gmail.com> writes:
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?
Sep 16 2020
parent reply Jacob Carlborg <doob me.com> writes:
On 2020-09-16 19:20, mw wrote:


 Why it's deprecated? can we revive it?


It was deprecated because it's a bad idea to not lock versions. Using 
`~master` would fetch the latest code from the "master" branch when 
compiling. You never know which version you get. You don't get 
reproducible builds.

-- 
/Jacob Carlborg
Sep 16 2020
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Wednesday, 16 September 2020 at 18:52:23 UTC, Jacob Carlborg 
wrote:

 On 2020-09-16 19:20, mw wrote:


 Why it's deprecated? can we revive it?


 It was deprecated because it's a bad idea to not lock versions. 
 Using `~master` would fetch the latest code from the "master" 
 branch when compiling. You never know which version you get. 
 You don't get reproducible builds.


I personally think it's not so bad as long as the commit gets 
written to the dub.selections.json
Sep 17 2020
parent reply Jacob Carlborg <doob me.com> writes:
On 2020-09-17 12:10, John Colvin wrote:


 I personally think it's not so bad as long as the commit gets written to 
 the dub.selections.json


It doesn't.

-- 
/Jacob Carlborg
Sep 18 2020
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Friday, 18 September 2020 at 13:35:34 UTC, Jacob Carlborg 
wrote:

 On 2020-09-17 12:10, John Colvin wrote:


 I personally think it's not so bad as long as the commit gets 
 written to the dub.selections.json


 It doesn't.


I know. But it should be.

But then again a lot of things “should be” with dub.
Sep 18 2020
parent Jacob Carlborg <doob me.com> writes:
On 2020-09-18 23:14, John Colvin wrote:


 I know. But it should be.


dub.selections.json wasn't available in the initial version. I don't 
remember if branches were deprecated before or after dub.selections.json 
was added.

-- 
/Jacob Carlborg
Sep 18 2020
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
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!
Sep 14 2020
prev sibling next sibling parent reply Martin Nowak <code dawg.eu> writes:
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.


The release candidate is live now.


 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
Sep 18 2020
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/18/20 1:16 PM, Martin Nowak 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.


 
 The release candidate is live now.
 

 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




This revert of the __traits(allMembers) change for imports is not 
included in this release candidate.

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

It needs to be included before the release, so that the import changes 
can be deferred until the next major.

-Steve
Sep 18 2020
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
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


We are currently evaluating if we should use D in our company in 
parts of our next service (I make the decision) and seeing 
evidence that D is alive and well is a big plus!

I wish I could contribute, but I'm not at that level in D yet 


Thanks!
Sep 19 2020
prev sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Friday, 11 September 2020 at 07:48:00 UTC, Martin Nowak wrote:

 http://dlang.org/changelog/2.094.0.html


Possible spell fix in Changelog. Shouldn't

"However, this didn't really capture the intended meaning of in: 
_the_ be applied on input parameters."

be

"However, this didn't really capture the intended meaning of in: 
_to_ be applied on input parameters."

?
Sep 19 2020