www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Release D 2.094.0

reply Martin Nowak <code dawg.eu> writes:
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
Sep 26
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
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! 🌈🍀
Sep 26
parent reply Daniel N <no public.email> writes:
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!
Sep 27
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
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
Oct 01
next sibling parent user1234 <user1234 12.de> writes:
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...)
Oct 01
prev sibling parent reply Mathias LANG <geod24 gmail.com> writes:
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.
Oct 01
next sibling parent reply Meta <jared771 gmail.com> writes:
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.
Oct 01
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
Oct 01
parent reply Meta <jared771 gmail.com> writes:
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
Oct 01
next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
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
Oct 01
prev sibling next sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
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.
Oct 01
prev sibling parent reply Mathias LANG <geod24 gmail.com> writes:
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 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.
Oct 01
parent reply Meta <jared771 gmail.com> writes:
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:
 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 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.
Oct 01
next sibling parent reply kinke <noone nowhere.com> writes:
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
Oct 01
parent reply Meta <jared771 gmail.com> writes:
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".
Oct 01
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
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.
Oct 02
prev sibling parent reply Seb <seb wilzba.ch> writes:
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 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.
Oct 01
parent reply Meta <jared771 gmail.com> writes:
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?
Oct 01
parent reply Seb <seb wilzba.ch> writes:
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.
Oct 01
parent Meta <jared771 gmail.com> writes:
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).
Oct 01
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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. "
Oct 01
parent jmh530 <john.michael.hall gmail.com> writes:
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...
Oct 01
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
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
Oct 02
prev sibling next sibling parent Martin Nowak <code dawg.eu> writes:
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
Sep 27
prev sibling next sibling parent reply apz28 <home home.com> writes:
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.
Sep 29
parent reply Basile B. <b2.temp gmx.com> writes:
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
Sep 30
parent Basile B. <b2.temp gmx.com> writes:
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,
Sep 30
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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 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?
Oct 04
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Oct 05
parent reply notna <notna.remove.this ist-einmalig.de> writes:
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-bugs puremagic.com - https://forum.dlang.org/post/mailman.2853.1587904820.31109.digitalmars-d-bugs puremagic.com - https://forum.dlang.org/post/fnaizrmuezxobtxlauci forum.dlang.org - https://forum.dlang.org/post/lwsekmmdlmfkhkahmucu forum.dlang.org - https://forum.dlang.org/post/szvratfzlyfbjeumabiy forum.dlang.org - https://forum.dlang.org/post/hpdxzlxwofpktlaaokuz 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
Oct 05
parent Andre Pany <andre s-e-a-p.de> writes:
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-bugs puremagic.com - https://forum.dlang.org/post/mailman.2853.1587904820.31109.digitalmars-d-bugs 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
Oct 05
prev sibling parent reply Anonymouse <zorael gmail.com> writes:
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?
Oct 11
parent user1234 <user1234 12.de> writes:
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.
Oct 11