digitalmars.D.announce - Release D 2.094.0

Martin Nowak (7/7) Sep 26 2020 Glad to announce D 2.094.0, ♥ to the 49 contributors.

Imperatorn (3/10) Sep 26 2020 Hurrah! 🌈🍀

Daniel N (2/15) Sep 27 2020 Yay! "-preview=in" is beyond epic!

Imperatorn (2/19) Oct 01 2020 I like epic things. What does it do? :D

user1234 (7/27) Oct 01 2020 "in" parameter storage class used to be like "const". with the
Mathias LANG (8/28) Oct 01 2020 Author here. The most complete way to know would be to read the

Meta (5/12) Oct 01 2020 Why was this added when we already have `auto ref`? Yes, it makes

Steven Schveighoffer (10/21) Oct 01 2020 There is a difference. `in` is choosing it based on the type, not

Meta (9/34) Oct 01 2020 This seems ridiculous to me. We now have ANOTHER way of asking

Steven Schveighoffer (11/24) Oct 01 2020 Whether a *const* piece of data is passed by reference or value is an
Petar Kirov [ZombineDev] (19/55) Oct 01 2020 `auto ref` is a mistake and shouldn't have existed. Thanks to
Mathias LANG (21/27) Oct 01 2020 Yes we have a 3rd way. Because `auto ref` just doesn't cut it for

Meta (15/43) Oct 01 2020 I've read the discussion but skipped the presentation. All I see

kinke (2/4) Oct 01 2020 https://github.com/dlang/dmd/pull/11000#issuecomment-675605193

Meta (4/8) Oct 01 2020 As far as I understand it, Andrei does not have any say over the

Andrei Alexandrescu (4/14) Oct 02 2020 That is correct, thanks for clarifying. Related: thanks Mathias for

Seb (11/57) Oct 01 2020 You seem to have a wrong understanding of -preview. It doesn't

Meta (4/34) Oct 01 2020 Okay, fair enough. Should this still not have had approval from

Seb (9/14) Oct 01 2020 Approval is not required for -preview. It's the testing phase of

Meta (5/20) Oct 01 2020 Okay, fair enough. Looks like I was mistaken and thought -preview

jmh530 (4/12) Oct 01 2020 Typo from the link

jmh530 (2/6) Oct 01 2020 It looks like that whole paragraph has a bunch of typos...

Imperatorn (2/18) Oct 02 2020 Thanks for the clarification

Martin Nowak (6/7) Sep 27 2020 I'd use the delay as an opportunity to shift the bi-monthly
apz28 (6/13) Sep 29 2020 Look like this build does not have ASSERT on.

Basile B. (8/24) Sep 30 2020 Only the version build during continuous have assert on since a

Basile B. (2/21) Sep 30 2020 *integration,

Andrej Mitrovic (17/24) Oct 04 2020 ```

Andrej Mitrovic (4/8) Oct 05 2020 This might have come off a bit rude, apologies for that.

notna (27/36) Oct 05 2020 Well, the "signature" topic is a constantly reoccurring issue and

Andre Pany (6/17) Oct 05 2020 I thought someone proposed to enhance the error message with the

Anonymouse (9/22) Oct 11 2020 Binaries took a while to hit Arch repositories, but now they did

user1234 (2/16) Oct 11 2020 No. It's because the AST has been optimized.

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

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 2020

D Programming

C/C++ Programming

Other

digitalmars.D.announce - Release D 2.094.0