digitalmars.D.announce - Beta 2.094.0
- Martin Nowak (9/9) Sep 11 2020 Glad to announce the first beta for the 2.094.0 release, ♥ to the
- Guillaume Piolat (8/17) Sep 11 2020 This is an absolutely fantastic release! Thanks to all.
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (5/7) Sep 12 2020 Is this solely thanks to using ldc as host compiler? What are the
- Iain Buclaw (5/7) Sep 13 2020 [--snip--]
- aberba (2/11) Sep 11 2020 Markdown 😎
- Andrej Mitrovic (6/10) Sep 11 2020 "Equality of arrays of structs is consistent again, as before
- kinke (6/12) Sep 12 2020 Looks like hardly anyone is affected, as the quite obviously
- MoonlightSentinel (2/6) Sep 12 2020 I think you mean -preview=dtorfields, not fieldwise.
- kinke (3/10) Sep 12 2020 Absolutely, thx for the correction.
- MoonlightSentinel (8/10) Sep 12 2020 Currently looking into enabling it by default but it showed an
- Paul Backus (20/26) Sep 12 2020 How many improvements does this warning have to block before we
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (3/8) Sep 12 2020 Attribute would be nice. Then such tagged exceptions can be
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (3/5) Sep 12 2020 There's also the option of improving the diagnostic of
- Paul Backus (6/12) Sep 12 2020 Is there? Issue 14835 was reported in 2015. If nobody's been able
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (6/13) Sep 12 2020 I agree, this is unfortunate. Did you read Andreis comment at the
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (2/4) Sep 12 2020 Here https://issues.dlang.org/show_bug.cgi?id=14835#c10
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (3/5) Sep 12 2020 I forgot too add the new formatting of -vtemplates to the
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (2/4) Sep 12 2020 https://github.com/dlang/dmd/pull/11463
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (2/4) Sep 12 2020 Where can I update the changelog to include this?
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (2/3) Sep 15 2020 https://github.com/dlang/dmd/pull/11732
- Manu (3/12) Sep 12 2020 What a monster release! We haven't had one like this for a while!
- Walter Bright (2/3) Sep 12 2020 Should be something for everyone in it :-)
- Walter Bright (3/5) Sep 12 2020 https://issues.dlang.org/show_bug.cgi?id=21241
- Walter Bright (4/17) Sep 12 2020 Thanks, Martin!
- MrSmith (16/25) Sep 13 2020 One unfortunate sideeffect of allMembers change is that it breaks
- Steven Schveighoffer (5/36) Sep 13 2020 The first part of the change seems disruptive. If you just fix the
- MrSmith (5/9) Sep 13 2020 Main problem is that allMembers returns strings and you can't
- Steven Schveighoffer (15/24) Sep 13 2020 It's always been string, and should always be.
- DlangUser38 (7/33) Sep 13 2020 Imports need to be fully qualified in the resulting tuple.
- Steven Schveighoffer (20/59) Sep 13 2020 I can't think of any other case where getting allMembers returns
- DlangUser38 (6/29) Sep 13 2020 I'm not sure if I react exactly to your answer but I agree that
- FeepingCreature (12/26) Sep 14 2020 I've tried to do this before and failed due to this bug. If it's
- Stefan Koch (9/21) Sep 15 2020 We should have the ability to get compiler tuple with the actual
- DlangUser38 (12/42) Sep 13 2020 the technic to filter out is:
- DlangUser38 (19/49) Sep 13 2020 https://github.com/dlang/dmd/pull/11727
- James Blachly (14/28) Sep 13 2020 The dub change allowing git repository is HUGE !
- mw (3/14) Sep 14 2020 On a git repo, where to get this version string?
- James Blachly (3/19) Sep 14 2020 Looks like the commit hash ; use `git log`
- mw (5/27) Sep 16 2020 Actually I just saw this:
- Jacob Carlborg (7/8) Sep 16 2020 It was deprecated because it's a bad idea to not lock versions. Using
- John Colvin (4/10) Sep 17 2020 I personally think it's not so bad as long as the commit gets
- Jacob Carlborg (4/6) Sep 18 2020 It doesn't.
- John Colvin (4/8) Sep 18 2020 I know. But it should be.
- Jacob Carlborg (6/7) Sep 18 2020 dub.selections.json wasn't available in the initial version. I don't
- Imperatorn (2/11) Sep 14 2020 Nice!
- Martin Nowak (2/11) Sep 18 2020
- Steven Schveighoffer (7/21) Sep 18 2020 This revert of the __traits(allMembers) change for imports is not
- Imperatorn (7/16) Sep 19 2020 We are currently evaluating if we should use D in our company in
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (8/9) Sep 19 2020 Possible spell fix in Changelog. Shouldn't
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
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 -MartinThis 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
On Friday, 11 September 2020 at 13:44:02 UTC, Guillaume Piolat wrote:This is an absolutely fantastic release! Thanks to all. - faster DMDIs 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
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 conversionThanks for the shout out, it's taken years to get it adopted by dmd. :-)
Sep 13 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 -MartinMarkdown 😎
Sep 11 2020
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
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
On Saturday, 12 September 2020 at 09:07:18 UTC, kinke wrote:On Saturday, 12 September 2020 at 00:52:43 UTC, Andrej MitrovicI think you mean -preview=dtorfields, not fieldwise.Does anyone know when -preview=fieldwise will become the default?FWIW, druntime and Phobos are compiled with it since v2.094.
Sep 12 2020
On Saturday, 12 September 2020 at 11:36:42 UTC, MoonlightSentinel wrote:On Saturday, 12 September 2020 at 09:07:18 UTC, kinke wrote:Absolutely, thx for the correction.On Saturday, 12 September 2020 at 00:52:43 UTC, Andrej MitrovicI think you mean -preview=dtorfields, not fieldwise.Does anyone know when -preview=fieldwise will become the default?FWIW, druntime and Phobos are compiled with it since v2.094.
Sep 12 2020
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
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
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:Attribute would be nice. Then such tagged exceptions can be searched for and maybe fixed later.Currently looking into enabling it by default but it showed an interesting side effect. The frontend
Sep 12 2020
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
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: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.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
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
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
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
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
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
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
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 -MartinWhat a monster release! We haven't had one like this for a while!
Sep 12 2020
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
On 9/11/2020 12:48 AM, Martin Nowak wrote:As usual please report any bugs at https://issues.dlang.orghttps://issues.dlang.org/show_bug.cgi?id=21241 (The changelog is basically illegible on Chrome.)
Sep 12 2020
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 -MartinThanks, 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
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 -MartinOne 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
On 9/13/20 10:52 AM, MrSmith wrote:On Friday, 11 September 2020 at 07:48:00 UTC, Martin Nowak 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? -SteveGlad 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 -MartinOne 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
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? -SteveMain 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
On 9/13/20 1:25 PM, MrSmith wrote:On Sunday, 13 September 2020 at 15:12:00 UTC, Steven Schveighoffer wrote: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. -SteveThe 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.
Sep 13 2020
On Sunday, 13 September 2020 at 17:51:49 UTC, Steven Schveighoffer wrote:On 9/13/20 1:25 PM, MrSmith wrote: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".On Sunday, 13 September 2020 at 15:12:00 UTC, Steven Schveighoffer wrote: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. -SteveThe 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.
Sep 13 2020
On 9/13/20 2:33 PM, DlangUser38 wrote:On Sunday, 13 September 2020 at 17:51:49 UTC, Steven Schveighoffer 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.On 9/13/20 1:25 PM, MrSmith wrote:Imports need to be fully qualified in the resulting tuple.On Sunday, 13 September 2020 at 15:12:00 UTC, Steven Schveighoffer wrote: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.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.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
On Sunday, 13 September 2020 at 19:16:24 UTC, Steven Schveighoffer wrote:On 9/13/20 2:33 PM, DlangUser38 wrote: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".[...]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
Sep 13 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. -SteveI'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
On Sunday, 13 September 2020 at 17:51:49 UTC, Steven Schveighoffer wrote:On 9/13/20 1:25 PM, MrSmith wrote: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) ?On Sunday, 13 September 2020 at 15:12:00 UTC, Steven Schveighoffer wrote:It's always been string, and should always be.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.
Sep 15 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: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.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 -MartinOne 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
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: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.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 -MartinOne 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
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 -MartinThe 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
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
On 9/14/20 5:17 PM, mw wrote:On Sunday, 13 September 2020 at 16:33:42 UTC, James Blachly wrote:Looks like the commit hash ; use `git log` Agree a branch name would be nice , then it could automatically take HEAD{ "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
On Monday, 14 September 2020 at 23:36:45 UTC, James Blachly wrote:On 9/14/20 5:17 PM, mw wrote: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?On Sunday, 13 September 2020 at 16:33:42 UTC, James Blachly wrote:Looks like the commit hash ; use `git log` Agree a branch name would be nice , then it could automatically take HEAD{ "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 16 2020
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
On Wednesday, 16 September 2020 at 18:52:23 UTC, Jacob Carlborg wrote:On 2020-09-16 19:20, mw wrote:I personally think it's not so bad as long as the commit gets written to the dub.selections.jsonWhy 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.
Sep 17 2020
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.jsonIt doesn't. -- /Jacob Carlborg
Sep 18 2020
On Friday, 18 September 2020 at 13:35:34 UTC, Jacob Carlborg wrote:On 2020-09-17 12:10, John Colvin wrote:I know. But it should be. But then again a lot of things “should be” with dub.I personally think it's not so bad as long as the commit gets written to the dub.selections.jsonIt doesn't.
Sep 18 2020
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
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 -MartinNice!
Sep 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.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
On 9/18/20 1:16 PM, Martin Nowak wrote:On Friday, 11 September 2020 at 07:48:00 UTC, Martin Nowak wrote: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. -SteveGlad 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
Sep 18 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 -MartinWe 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
On Friday, 11 September 2020 at 07:48:00 UTC, Martin Nowak wrote:http://dlang.org/changelog/2.094.0.htmlPossible 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