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.
LDC 1.24.0-beta1
Glad to announce the first beta for LDC 1.24: - Based on D 2.094.0+. - Support for LLVM 11. The prebuilt packages use v11.0.0-rc4+, and the x86 packages newly include the LLVM backend for AMD GPUs. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.24.0-beta1 Please help test, and thanks to all contributors & sponsors!
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: Sociomantic Tsunami now under new community maintainership
On Wednesday, 30 September 2020 at 08:31:25 UTC, Iain Buclaw wrote: [..] Great news, thank you Iain and everyone else who was responsible! I think an overview of those D projects would make for a great DConf talk!
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: Sociomantic Tsunami now under new community maintainership
On Wednesday, 30 September 2020 at 08:31:25 UTC, Iain Buclaw wrote: I would like to thank dunnhumby for being supportive throughout the entire process, and for handling the transition in a gracious fashion since operations began winding down. I would second those thanks, and would also like to offer a big hand to Iain for stewarding this whole process.
Re: Sociomantic Tsunami now under new community maintainership
On Thursday, 1 October 2020 at 07:43:38 UTC, Imperatorn wrote: On Wednesday, 30 September 2020 at 08:31:25 UTC, Iain Buclaw wrote: Hello Everybody, Tsunami is a set of core libraries, applications, and tools that were used at sociomantic labs/dunnhumby Germany, and have been available as open-source software since 2017 under the direction and management of dunnhumby. [...] Cool. Are those projects on dub as well? Ocean is up to date and on dub: https://code.dlang.org/packages/ocean Adding dub config to the other projects is planned, and we'd welcome patches if anyone wants to speed up that process.
Re: Sociomantic Tsunami now under new community maintainership
On Wednesday, 30 September 2020 at 08:31:25 UTC, Iain Buclaw wrote: Hello Everybody, Tsunami is a set of core libraries, applications, and tools that were used at sociomantic labs/dunnhumby Germany, and have been available as open-source software since 2017 under the direction and management of dunnhumby. [...] Cool. Are those projects on dub as well?
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
