Re: Release D 2.094.0
On Sunday, 11 October 2020 at 15:52:19 UTC, Anonymouse wrote: On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak Binaries took a while to hit Arch repositories, but now they did and I'm immediately pleasantly surprised. 2.093.1: $ time dub build -c dev Performing "debug" build using dmd for x86_64. [...] max memory:3598 MB 2.094.0: $ time dub build -c dev Performing "debug" build using dmd for x86_64. [...] max memory:3277 MB Is it because of dmd being built with ldc? No. It's because the AST has been optimized.
Re: Release D 2.094.0
On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics. http://dlang.org/download.html http://dlang.org/changelog/2.094.0.html -Martin Binaries took a while to hit Arch repositories, but now they did and I'm immediately pleasantly surprised. 2.093.1: $ time dub build -c dev Performing "debug" build using dmd for x86_64. [...] max memory:3598 MB 2.094.0: $ time dub build -c dev Performing "debug" build using dmd for x86_64. [...] max memory:3277 MB Is it because of dmd being built with ldc?
Re: Release D 2.094.0
On Monday, 5 October 2020 at 13:56:51 UTC, notna wrote: On Monday, 5 October 2020 at 09:17:13 UTC, Andrej Mitrovic wrote: [...] Well, the "signature" topic is a constantly reoccurring issue and you can find plenty complains in the news group / forum... some examples: - https://forum.dlang.org/post/mailman.3930.1592291554.31109.digitalmars-d-b...@puremagic.com - https://forum.dlang.org/post/mailman.2853.1587904820.31109.digitalmars-d-b...@puremagic.com [...] I thought someone proposed to enhance the error message with the info about the update command. This would be a starting point and easy to implement. Kind regards Andre
Re: Release D 2.094.0
On Monday, 5 October 2020 at 09:17:13 UTC, Andrej Mitrovic wrote: On Monday, 5 October 2020 at 03:27:22 UTC, Andrej Mitrovic wrote: I'm not sure if it's related to https://issues.dlang.org/show_bug.cgi?id=21226. But how many people will be turned away not being able to install the compiler? This might have come off a bit rude, apologies for that. That being said, the solution seemed to be to run the `update` command on the script. It wasn't really obvious though. Well, the "signature" topic is a constantly reoccurring issue and you can find plenty complains in the news group / forum... some examples: - https://forum.dlang.org/post/mailman.3930.1592291554.31109.digitalmars-d-b...@puremagic.com - https://forum.dlang.org/post/mailman.2853.1587904820.31109.digitalmars-d-b...@puremagic.com - https://forum.dlang.org/post/fnaizrmuezxobtxla...@forum.dlang.org - https://forum.dlang.org/post/lwsekmmdlmfkhkahm...@forum.dlang.org - https://forum.dlang.org/post/szvratfzlyfbjeuma...@forum.dlang.org - https://forum.dlang.org/post/hpdxzlxwofpktlaao...@forum.dlang.org I made a quick enhancement proposal as suggested by Seb before / here - https://github.com/dlang/dlang.org/pull/2817#pullrequestreview-425842582 ... my pull request was merged but later reverted again: - https://github.com/dlang/installer/pull/457 - https://github.com/dlang/installer/pull/302 Seb promised to work on it... whenever he finds the need and time for it. Mybe someone else can continue / implement / drive this "auto update" topic... regards
Re: Release D 2.094.0
On Monday, 5 October 2020 at 03:27:22 UTC, Andrej Mitrovic wrote: I'm not sure if it's related to https://issues.dlang.org/show_bug.cgi?id=21226. But how many people will be turned away not being able to install the compiler? This might have come off a bit rude, apologies for that. That being said, the solution seemed to be to run the `update` command on the script. It wasn't really obvious though.
Re: Release D 2.094.0
On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics. http://dlang.org/download.html http://dlang.org/changelog/2.094.0.html -Martin ``` $ curl -fsS https://dlang.org/install.sh | bash -s dmd Downloading and unpacking http://downloads.dlang.org/releases/2.x/2.094.0/dmd.2.094.0.osx.tar.xz 100.0% gpg: Signature made Tue Sep 22 18:58:37 2020 KST gpg:using RSA key 3AAF1A18E61F6FAA3B7193E4DB8C5218B9329CF8 gpg: Can't check signature: No public key Invalid signature http://downloads.dlang.org/releases/2.x/2.094.0/dmd.2.094.0.osx.tar.xz.sig ``` I'm not sure if it's related to https://issues.dlang.org/show_bug.cgi?id=21226. But how many people will be turned away not being able to install the compiler?
Re: Release D 2.094.0
On 10/1/20 5:08 PM, Meta wrote: On Thursday, 1 October 2020 at 20:37:04 UTC, kinke wrote: On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote: If W or A did approve it and I just wasn't aware, then I apologize and retract my objection. https://github.com/dlang/dmd/pull/11000#issuecomment-675605193 As far as I understand it, Andrei does not have any say over the direction of the language anymore since he stepped down. By "W or A" I meant "Walter or Atila". That is correct, thanks for clarifying. Related: thanks Mathias for working on improving the status quo in function parameter modifiers. Any shake of that rusty nail is likely to improve matters.
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 09:49:36 UTC, Mathias LANG wrote: On Thursday, 1 October 2020 at 07:02:12 UTC, Imperatorn wrote: On Sunday, 27 September 2020 at 19:20:34 UTC, Daniel N wrote: On Saturday, 26 September 2020 at 22:12:17 UTC, Imperatorn wrote: [...] Yay! "-preview=in" is beyond epic! I like epic things. What does it do? :D Author here. The most complete way to know would be to read the changelog: https://dlang.org/changelog/2.094.0.html#preview-in The TL;DR is that, in addition to `const scope`, `in` now automatically behaves as `ref` when "it makes sense" such as large value types or presence of destructors / postblit (more details in the changelog!) and will accept rvalues, unlike other ref parameters. Thanks for the clarification
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 21:19:02 UTC, Seb wrote: On Thursday, 1 October 2020 at 21:09:55 UTC, Meta wrote: On Thursday, 1 October 2020 at 20:40:39 UTC, Seb wrote: [...] Okay, fair enough. Should this still not have had approval from either Walter or Atila before being merged in? Or is that not the case for changes behind -preview? Approval is not required for -preview. It's the testing phase of a new feature or change. As I tried to mention earlier real data and experimentation is super helpful for a DIP / formal approval (in this case one important question answered was how much code in the D ecosystem would need to be changed). There's a bit of implicit approval by no objection as something that's worthwhile to be explored/tested, but it's only a good chance that it will be activated by default, not a guarantee. Okay, fair enough. Looks like I was mistaken and thought -preview implied that the feature will be moved out from under the switch after a certain number of releases (as the word "preview" means an early look at something that will be released in the future).
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 21:09:55 UTC, Meta wrote: On Thursday, 1 October 2020 at 20:40:39 UTC, Seb wrote: [...] Okay, fair enough. Should this still not have had approval from either Walter or Atila before being merged in? Or is that not the case for changes behind -preview? Approval is not required for -preview. It's the testing phase of a new feature or change. As I tried to mention earlier real data and experimentation is super helpful for a DIP / formal approval (in this case one important question answered was how much code in the D ecosystem would need to be changed). There's a bit of implicit approval by no objection as something that's worthwhile to be explored/tested, but it's only a good chance that it will be activated by default, not a guarantee.
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 20:40:39 UTC, Seb wrote: On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote: I've read the discussion but skipped the presentation. All I see is Atila expressing distaste for the compiler choosing how to pass values, and no explicit sign-off from either Walter or Atila before it was merged. My objection is not to `in`'s new behaviour (although having something that functions similarly to auto ref but in subtly different ways is not good language design, IMO). My objection is that we have a major change to a language feature, that was merged without the apparent blessing of either of the two people who are supposed to be the gatekeepers for these decisions, and without a DIP (yes, it is behind -preview, but that implies that this will eventually make it into the language proper). That is what I am calling "ridiculous". If W or A did approve it and I just wasn't aware, then I apologize and retract my objection. You seem to have a wrong understanding of -preview. It doesn't even pretend to be an officially approved feature. I think this is what's been causing the confusion. Preview flags are what other compilers call "experimental". In fact, -preview is intended to predate a DIP or formal approval in other ways, because if you don't know the impact of a feature or usefulness, it's very hard to make an informed decision. This has the nice side effect that sometimes it becomes clear during an implementation that the idea as is unfeasible. implies that this will eventually make it into the language proper No, it doesn't. Okay, fair enough. Should this still not have had approval from either Walter or Atila before being merged in? Or is that not the case for changes behind -preview?
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 20:37:04 UTC, kinke wrote: On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote: If W or A did approve it and I just wasn't aware, then I apologize and retract my objection. https://github.com/dlang/dmd/pull/11000#issuecomment-675605193 As far as I understand it, Andrei does not have any say over the direction of the language anymore since he stepped down. By "W or A" I meant "Walter or Atila".
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote: On Thursday, 1 October 2020 at 17:29:56 UTC, Mathias LANG wrote: On Thursday, 1 October 2020 at 16:47:37 UTC, Meta wrote: [...] Yes we have a 3rd way. Because `auto ref` just doesn't cut it for most usages, and `-preview=rvaluerefparam` never worked. You can have a look at the full discussion in the PR that introduced it (dmd#11000). I try to summarize a few arguments in favor of it here: https://github.com/dlang/dmd/pull/11000#issuecomment-674498704 As you can see from the discussion, it's not really something that was quickly merged, but the results of months of work. So while it might seems "ridiculous" to you, I'd appreciate if you could take the time to read through the discussion, as well as taking a look at Herb Sutter's presentation which was linked. The key takeaway from that presentation is that instead of having the users specify *how* to pass the parameter, they should specify what is the parameter's semantic. In our case, input (in), output (out), or input/output (ref). I'm not aware of a situation where you want to use `auto ref` on a parameter without `const` (or `const` semantic), because if you intend to modify the parameter, you need to be sure whether it's `ref` or not. I'm aware some people use it for forwarding but this has its own set of problem. I've read the discussion but skipped the presentation. All I see is Atila expressing distaste for the compiler choosing how to pass values, and no explicit sign-off from either Walter or Atila before it was merged. My objection is not to `in`'s new behaviour (although having something that functions similarly to auto ref but in subtly different ways is not good language design, IMO). My objection is that we have a major change to a language feature, that was merged without the apparent blessing of either of the two people who are supposed to be the gatekeepers for these decisions, and without a DIP (yes, it is behind -preview, but that implies that this will eventually make it into the language proper). That is what I am calling "ridiculous". If W or A did approve it and I just wasn't aware, then I apologize and retract my objection. You seem to have a wrong understanding of -preview. It doesn't even pretend to be an officially approved feature. I think this is what's been causing the confusion. Preview flags are what other compilers call "experimental". In fact, -preview is intended to predate a DIP or formal approval in other ways, because if you don't know the impact of a feature or usefulness, it's very hard to make an informed decision. This has the nice side effect that sometimes it becomes clear during an implementation that the idea as is unfeasible. implies that this will eventually make it into the language proper No, it doesn't.
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 16:47:37 UTC, Meta wrote: This seems ridiculous to me. We now have ANOTHER way of asking the compiler to choose for us whether to pass by ref or by value, completely mutually exclusive of auto ref. Where was the DIP (apologies if I just didn't see it)? Did Walter approve this? How do we explain the difference between in and auto ref with (as Andrei would say) a straight face? Yes we have a 3rd way. Because `auto ref` just doesn't cut it for most usages, and `-preview=rvaluerefparam` never worked. You can have a look at the full discussion in the PR that introduced it (dmd#11000). I try to summarize a few arguments in favor of it here: https://github.com/dlang/dmd/pull/11000#issuecomment-674498704 As you can see from the discussion, it's not really something that was quickly merged, but the results of months of work. So while it might seems "ridiculous" to you, I'd appreciate if you could take the time to read through the discussion, as well as taking a look at Herb Sutter's presentation which was linked. The key takeaway from that presentation is that instead of having the users specify *how* to pass the parameter, they should specify what is the parameter's semantic. In our case, input (in), output (out), or input/output (ref). I'm not aware of a situation where you want to use `auto ref` on a parameter without `const` (or `const` semantic), because if you intend to modify the parameter, you need to be sure whether it's `ref` or not. I'm aware some people use it for forwarding but this has its own set of problem.
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 16:47:37 UTC, Meta wrote: On Thursday, 1 October 2020 at 16:19:48 UTC, Steven Schveighoffer wrote: On 10/1/20 10:36 AM, Meta wrote: On Thursday, 1 October 2020 at 09:49:36 UTC, Mathias LANG wrote: Author here. The most complete way to know would be to read the changelog: https://dlang.org/changelog/2.094.0.html#preview-in The TL;DR is that, in addition to `const scope`, `in` now automatically behaves as `ref` when "it makes sense" such as large value types or presence of destructors / postblit (more details in the changelog!) and will accept rvalues, unlike other ref parameters. Why was this added when we already have `auto ref`? Yes, it makes the function a template, but if `in` can automatically choose whether the variable is ref or not, then auto ref could easily do the same. There is a difference. `in` is choosing it based on the type, not whether it's an rvalue or lvalue. auto ref doesn't care whether it's an int or a 1k-sized struct, if it's an lvalue, it's ref, and if it's an rvalue, it's non-ref. This seems ridiculous to me. We now have ANOTHER way of asking the compiler to choose for us whether to pass by ref or by value, completely mutually exclusive of auto ref. Where was the DIP (apologies if I just didn't see it)? Did Walter approve this? How do we explain the difference between in and auto ref with (as Andrei would say) a straight face? `auto ref` is a mistake and shouldn't have existed. Thanks to Mathias, `in` parameters are finally working the way most sane people expect them to work. I can't quite explain `auto ref` with straight face, while to explain `in` I just need to say "unless you're mutating or aliasing the parameter always mark it as `in`". Not only that, but every auto-ref parameter is another template parameter varying on the usage. So calling on an lvalue and rvalue will generate 2 separate mostly-identical functions. With -preview=in, only one function is generated per type. That's a QOI problem IMO. No, it's not. According the spec, `auto ref` parameters can only be used for templates (making them useless for virtual functions and delegates) and the compiler is required to generate a different functions depending on whether the parameter is an lvalue or an rvalue, which completely misses the point. There's code out there that expect two instances to be generated and distinguishes which one it's in using `static if (__traits(isRef, param))`. You can't change this behavior without breaking code, so it's not a QoI problem. On the other hand, now the `in` parameter storage class finally has the opposite meaning of `out`. Makes code more elegant to write, easier to explain and teach.
Re: Release D 2.094.0
On 10/1/20 12:47 PM, Meta wrote: On Thursday, 1 October 2020 at 16:19:48 UTC, Steven Schveighoffer wrote: There is a difference. `in` is choosing it based on the type, not whether it's an rvalue or lvalue. auto ref doesn't care whether it's an int or a 1k-sized struct, if it's an lvalue, it's ref, and if it's an rvalue, it's non-ref. This seems ridiculous to me. We now have ANOTHER way of asking the compiler to choose for us whether to pass by ref or by value, completely mutually exclusive of auto ref. Where was the DIP (apologies if I just didn't see it)? Did Walter approve this? How do we explain the difference between in and auto ref with (as Andrei would say) a straight face? Whether a *const* piece of data is passed by reference or value is an implementation detail -- you can't change it anyway. I don't want the compiler to pass const integers by reference -- that's wasteful. auto ref is a different problem -- the data might be mutable, which makes an actual difference in semantics. But this brings up a problem which I don't know if it was discussed -- aliasing. What if you pass in the same value in 2 parameters, one ref and one in. And you change the value via the ref. What happens to the in parameter? -Steve
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 16:19:48 UTC, Steven Schveighoffer wrote: On 10/1/20 10:36 AM, Meta wrote: On Thursday, 1 October 2020 at 09:49:36 UTC, Mathias LANG wrote: Author here. The most complete way to know would be to read the changelog: https://dlang.org/changelog/2.094.0.html#preview-in The TL;DR is that, in addition to `const scope`, `in` now automatically behaves as `ref` when "it makes sense" such as large value types or presence of destructors / postblit (more details in the changelog!) and will accept rvalues, unlike other ref parameters. Why was this added when we already have `auto ref`? Yes, it makes the function a template, but if `in` can automatically choose whether the variable is ref or not, then auto ref could easily do the same. There is a difference. `in` is choosing it based on the type, not whether it's an rvalue or lvalue. auto ref doesn't care whether it's an int or a 1k-sized struct, if it's an lvalue, it's ref, and if it's an rvalue, it's non-ref. This seems ridiculous to me. We now have ANOTHER way of asking the compiler to choose for us whether to pass by ref or by value, completely mutually exclusive of auto ref. Where was the DIP (apologies if I just didn't see it)? Did Walter approve this? How do we explain the difference between in and auto ref with (as Andrei would say) a straight face? Not only that, but every auto-ref parameter is another template parameter varying on the usage. So calling on an lvalue and rvalue will generate 2 separate mostly-identical functions. With -preview=in, only one function is generated per type. That's a QOI problem IMO. -Steve
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 09:49:36 UTC, Mathias LANG wrote: [snip] Author here. The most complete way to know would be to read the changelog: https://dlang.org/changelog/2.094.0.html#preview-in The TL;DR is that, in addition to `const scope`, `in` now automatically behaves as `ref` when "it makes sense" such as large value types or presence of destructors / postblit (more details in the changelog!) and will accept rvalues, unlike other ref parameters. Typo from the link "However, this didn't really capture the intended meaning of in: the be applied on input parameters. "
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 16:44:09 UTC, jmh530 wrote: [snip] Typo from the link "However, this didn't really capture the intended meaning of in: the be applied on input parameters. " It looks like that whole paragraph has a bunch of typos...
Re: Release D 2.094.0
On 10/1/20 10:36 AM, Meta wrote: On Thursday, 1 October 2020 at 09:49:36 UTC, Mathias LANG wrote: Author here. The most complete way to know would be to read the changelog: https://dlang.org/changelog/2.094.0.html#preview-in The TL;DR is that, in addition to `const scope`, `in` now automatically behaves as `ref` when "it makes sense" such as large value types or presence of destructors / postblit (more details in the changelog!) and will accept rvalues, unlike other ref parameters. Why was this added when we already have `auto ref`? Yes, it makes the function a template, but if `in` can automatically choose whether the variable is ref or not, then auto ref could easily do the same. There is a difference. `in` is choosing it based on the type, not whether it's an rvalue or lvalue. auto ref doesn't care whether it's an int or a 1k-sized struct, if it's an lvalue, it's ref, and if it's an rvalue, it's non-ref. Not only that, but every auto-ref parameter is another template parameter varying on the usage. So calling on an lvalue and rvalue will generate 2 separate mostly-identical functions. With -preview=in, only one function is generated per type. -Steve
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 09:49:36 UTC, Mathias LANG wrote: Author here. The most complete way to know would be to read the changelog: https://dlang.org/changelog/2.094.0.html#preview-in The TL;DR is that, in addition to `const scope`, `in` now automatically behaves as `ref` when "it makes sense" such as large value types or presence of destructors / postblit (more details in the changelog!) and will accept rvalues, unlike other ref parameters. Why was this added when we already have `auto ref`? Yes, it makes the function a template, but if `in` can automatically choose whether the variable is ref or not, then auto ref could easily do the same.
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 07:02:12 UTC, Imperatorn wrote: On Sunday, 27 September 2020 at 19:20:34 UTC, Daniel N wrote: On Saturday, 26 September 2020 at 22:12:17 UTC, Imperatorn wrote: On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics. http://dlang.org/download.html http://dlang.org/changelog/2.094.0.html -Martin Hurrah! Yay! "-preview=in" is beyond epic! I like epic things. What does it do? :D Author here. The most complete way to know would be to read the changelog: https://dlang.org/changelog/2.094.0.html#preview-in The TL;DR is that, in addition to `const scope`, `in` now automatically behaves as `ref` when "it makes sense" such as large value types or presence of destructors / postblit (more details in the changelog!) and will accept rvalues, unlike other ref parameters.
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 07:02:12 UTC, Imperatorn wrote: On Sunday, 27 September 2020 at 19:20:34 UTC, Daniel N wrote: On Saturday, 26 September 2020 at 22:12:17 UTC, Imperatorn wrote: On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics. http://dlang.org/download.html http://dlang.org/changelog/2.094.0.html -Martin Hurrah! Yay! "-preview=in" is beyond epic! I like epic things. What does it do? :D "in" parameter storage class used to be like "const". with the preview it has its own semantics, i.e like "scope const". But it's a preview because people tend to use "in" because it was shorter than "const" so many code base are poisoned with this misuse (although in plenty of case the new semantics probably dont cause bugs...)
Re: Release D 2.094.0
On Sunday, 27 September 2020 at 19:20:34 UTC, Daniel N wrote: On Saturday, 26 September 2020 at 22:12:17 UTC, Imperatorn wrote: On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics. http://dlang.org/download.html http://dlang.org/changelog/2.094.0.html -Martin Hurrah! Yay! "-preview=in" is beyond epic! I like epic things. What does it do? :D
Re: Release D 2.094.0
On Wednesday, 30 September 2020 at 18:38:25 UTC, Basile B. wrote: On Tuesday, 29 September 2020 at 13:38:58 UTC, apz28 wrote: On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics. http://dlang.org/download.html http://dlang.org/changelog/2.094.0.html -Martin Look like this build does not have ASSERT on. I have a VisualD project that build successfully in release but fail in debug without any error message - it fails in "semantic3" step on one of the module. Only the version build during continuous *integration,
Re: Release D 2.094.0
On Tuesday, 29 September 2020 at 13:38:58 UTC, apz28 wrote: On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics. http://dlang.org/download.html http://dlang.org/changelog/2.094.0.html -Martin Look like this build does not have ASSERT on. I have a VisualD project that build successfully in release but fail in debug without any error message - it fails in "semantic3" step on one of the module. Only the version build during continuous have assert on since a few weeks [1]. The PR that should have allowed the same in the official release [2] has been closed by error, hence the changelog lead to a wrong idea about the current state of assert in the compiler itself. [1] https://github.com/dlang/dmd/pull/11523 [2] https://github.com/dlang/dmd/pull/10679
Re: Release D 2.094.0
On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics. http://dlang.org/download.html http://dlang.org/changelog/2.094.0.html -Martin Look like this build does not have ASSERT on. I have a VisualD project that build successfully in release but fail in debug without any error message - it fails in "semantic3" step on one of the module.
Re: Release D 2.094.0
On Saturday, 26 September 2020 at 22:12:17 UTC, Imperatorn wrote: On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics. http://dlang.org/download.html http://dlang.org/changelog/2.094.0.html -Martin Hurrah! Yay! "-preview=in" is beyond epic!
Re: Release D 2.094.0
On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. I'd use the delay as an opportunity to shift the bi-monthly releases to even months (to avoid the beta during the holiday season). https://github.com/dlang/dlang.org/pull/2860
Re: Release D 2.094.0
On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics. http://dlang.org/download.html http://dlang.org/changelog/2.094.0.html -Martin Hurrah!
