www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Preview features status?

reply evilrat <evilrat666 gmail.com> writes:
There were recently new additions to -preview flag, will they 
stay? Is preview features generally means it is not going to be 
removed later?

Specifically what about these two?

-preview=rvaluerefparam
This one helps with C++ interop where it's the norm but is PITA 
in D.

-preview=shortenedMethods
And this one just gives nice and fresh look to the language
May 19
parent reply evilrat <evilrat666 gmail.com> writes:
On Wednesday, 19 May 2021 at 07:36:53 UTC, evilrat wrote:
 -preview=rvaluerefparam
 This one helps with C++ interop where it's the norm but is PITA 
 in D.
Well, ok D still got me sometimes even with that preview feature, this s**t isn't even fun... ```d // PxVec3 operator- public PxVec3 opBinary(string op : "-")(ref const(PxVec3) v) const { return PxVec3(x - v.x, y - v.y, z - v.z); } public float distance(ref const(PxVec3) p) const { return p.dot(n) + d; // dot is also const } // original code, n is plain PxVec3, not const public PxVec3 project(ref const(PxVec3) p) const { return p - n * distance(p); // error } ```
 Error: incompatible types for `(p) - 
 (this.n.opBinary(this.distance(p)))`: `const(PxVec3)` and 
 `PxVec3`
```d // lets try this public PxVec3 project(ref const(PxVec3) p) const { PxVec3 t = p; return t - n * distance(t); // error } ```
 Error: incompatible types for `(t) - 
 (this.n.opBinary(this.distance(t)))`: both operands are of type 
 `PxVec3`
```d // ok, no error public PxVec3 project(ref const(PxVec3) p) const { auto t = n * distance(p); pragma(msg, typeof(t)); // PxVec3 return p - t; // } U MAD BRO? ```
May 19
parent reply Tejas <notrealemail gmail.com> writes:
On Wednesday, 19 May 2021 at 08:45:22 UTC, evilrat wrote:
 On Wednesday, 19 May 2021 at 07:36:53 UTC, evilrat wrote:
 -preview=rvaluerefparam
 This one helps with C++ interop where it's the norm but is 
 PITA in D.
Well, ok D still got me sometimes even with that preview feature, this s**t isn't even fun... ```d // PxVec3 operator- public PxVec3 opBinary(string op : "-")(ref const(PxVec3) v) const { return PxVec3(x - v.x, y - v.y, z - v.z); } public float distance(ref const(PxVec3) p) const { return p.dot(n) + d; // dot is also const } // original code, n is plain PxVec3, not const public PxVec3 project(ref const(PxVec3) p) const { return p - n * distance(p); // error } ```
 Error: incompatible types for `(p) - 
 (this.n.opBinary(this.distance(p)))`: `const(PxVec3)` and 
 `PxVec3`
```d // lets try this public PxVec3 project(ref const(PxVec3) p) const { PxVec3 t = p; return t - n * distance(t); // error } ```
 Error: incompatible types for `(t) - 
 (this.n.opBinary(this.distance(t)))`: both operands are of 
 type `PxVec3`
```d // ok, no error public PxVec3 project(ref const(PxVec3) p) const { auto t = n * distance(p); pragma(msg, typeof(t)); // PxVec3 return p - t; // } U MAD BRO? ```
Shouldn't this be a bug? Isn't this still ```const - non-const```? Do you think this is worth filing? Also, where did you find out how to represent rvalue references as parameters? I couldn't find any info on that. Just learned that these are available under a preview switch.
Jul 13
parent reply evilrat <evilrat666 gmail.com> writes:
On Tuesday, 13 July 2021 at 15:51:26 UTC, Tejas wrote:
 Shouldn't this be a bug? Isn't this still ```const - 
 non-const```?
 Do you think this is worth filing?
Definitely a bug from usability point. But... Well, seems like it is just yet another half baked feature according to this GH issue, also it seems like it was supposed to be superseded by relevant "in" qualifier for extern(C++) but that DIP seems to be abandoned as well. https://github.com/dlang/dmd/pull/12064
 Also, where did you find out how to represent rvalue references 
 as parameters? I couldn't find any info on that. Just learned 
 that these are available under a preview switch.
Can't find it anywhere in release notes, it was just silently showed up around Apr 2019.
Jul 13
next sibling parent reply Mathias LANG <geod24 gmail.com> writes:
On Tuesday, 13 July 2021 at 18:20:36 UTC, evilrat wrote:
 On Tuesday, 13 July 2021 at 15:51:26 UTC, Tejas wrote:
 Shouldn't this be a bug? Isn't this still ```const - 
 non-const```?
 Do you think this is worth filing?
Definitely a bug from usability point. But... Well, seems like it is just yet another half baked feature according to this GH issue, also it seems like it was supposed to be superseded by relevant "in" qualifier for extern(C++) but that DIP seems to be abandoned as well. https://github.com/dlang/dmd/pull/12064
 Also, where did you find out how to represent rvalue 
 references as parameters? I couldn't find any info on that. 
 Just learned that these are available under a preview switch.
Can't find it anywhere in release notes, it was just silently showed up around Apr 2019.
Here's the full picture from my POV: `-preview=rvaluerefparams` was [implemented by Walter](https://github.com/dlang/dmd/pull/9817) and later [documented](https://github.com/dlang/dmd/pull/10633). However when I tried to use it, I ran into the three issues that were linked in the PR you mentioned. I originally started working on fixing those, but realized that there were many unanswered questions. One of them was, what to do with mutable parameters ? This was one of the main rationale provided when [the DIP](https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md) was rejected. This brought me back to an old idea of mine, which was to have `in` means `const scope [ref]` (`ref` when it makes sense), but the fact that it would conflict with passing rvalues to a function was always off-putting. Adding rvalue ref matching just made sense, so I went ahead and [implemented it](https://github.com/dlang/dmd/pull/11000). I also made sure druntime/Phobos, Vibe.d, [and many other packages on Buildkite](https://github.com/dlang/dmd/pull/11632) were compatible. I've been using it in production as soon as I could, which was v2.094.0 because [`-preview` flags and DUB didn't play along well before](https://github.com/dlang/dub/pull/2040). It's been a breeze, and doing everything exactly as we want it done, so I'm very happy with the result. However, there has been some serious backlash from a few people. So I don't think it's going to be made the default any time soon (or at least, start the process), because it seems Walter is among those who doesn't like it. So unless we manage to convince the BDFLs that it's useful, it's not going out of `-preview`. However, I'll make sure it works in every release, as I use it everywhere.
Jul 13
parent Tejas <notrealemail gmail.com> writes:
On Wednesday, 14 July 2021 at 02:54:26 UTC, Mathias LANG wrote:
 On Tuesday, 13 July 2021 at 18:20:36 UTC, evilrat wrote:
 On Tuesday, 13 July 2021 at 15:51:26 UTC, Tejas wrote:
 Shouldn't this be a bug? Isn't this still ```const - 
 non-const```?
 Do you think this is worth filing?
Definitely a bug from usability point. But... Well, seems like it is just yet another half baked feature according to this GH issue, also it seems like it was supposed to be superseded by relevant "in" qualifier for extern(C++) but that DIP seems to be abandoned as well. https://github.com/dlang/dmd/pull/12064
 Also, where did you find out how to represent rvalue 
 references as parameters? I couldn't find any info on that. 
 Just learned that these are available under a preview switch.
Can't find it anywhere in release notes, it was just silently showed up around Apr 2019.
Here's the full picture from my POV: `-preview=rvaluerefparams` was [implemented by Walter](https://github.com/dlang/dmd/pull/9817) and later [documented](https://github.com/dlang/dmd/pull/10633). However when I tried to use it, I ran into the three issues that were linked in the PR you mentioned. I originally started working on fixing those, but realized that there were many unanswered questions. One of them was, what to do with mutable parameters ? This was one of the main rationale provided when [the DIP](https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md) was rejected. This brought me back to an old idea of mine, which was to have `in` means `const scope [ref]` (`ref` when it makes sense), but the fact that it would conflict with passing rvalues to a function was always off-putting. Adding rvalue ref matching just made sense, so I went ahead and [implemented it](https://github.com/dlang/dmd/pull/11000). I also made sure druntime/Phobos, Vibe.d, [and many other packages on Buildkite](https://github.com/dlang/dmd/pull/11632) were compatible. I've been using it in production as soon as I could, which was v2.094.0 because [`-preview` flags and DUB didn't play along well before](https://github.com/dlang/dub/pull/2040). It's been a breeze, and doing everything exactly as we want it done, so I'm very happy with the result. However, there has been some serious backlash from a few people. So I don't think it's going to be made the default any time soon (or at least, start the process), because it seems Walter is among those who doesn't like it. So unless we manage to convince the BDFLs that it's useful, it's not going out of `-preview`. However, I'll make sure it works in every release, as I use it everywhere.
I believe you're talking about this? https://forum.dlang.org/thread/rl7c8t$sml$1 digitalmars.com Well, I admit that their concerns aren't unfounded, but since yours is the only proposal still being maintained and worked on, we can try and think of ways regarding how to $(I deterministically) specify whether to receive an rvalue ref, or rvalue, or lvalue ref, or lvalue. ```in``` could use deeper formalism, or we could try to develop a pass that checks for the aliases in the particular case shown. Either way, since ```in``` is the only game in town, I guess. I'll also use it. Thanks for your work in developing and maintaining it. Nothing's perfect the first time around :)
Jul 14
prev sibling parent reply Tejas <notrealemail gmail.com> writes:
On Tuesday, 13 July 2021 at 18:20:36 UTC, evilrat wrote:
 On Tuesday, 13 July 2021 at 15:51:26 UTC, Tejas wrote:
 Shouldn't this be a bug? Isn't this still ```const - 
 non-const```?
 Do you think this is worth filing?
Definitely a bug from usability point. But... Well, seems like it is just yet another half baked feature according to this GH issue, also it seems like it was supposed to be superseded by relevant "in" qualifier for extern(C++) but that DIP seems to be abandoned as well. https://github.com/dlang/dmd/pull/12064
 Also, where did you find out how to represent rvalue 
 references as parameters? I couldn't find any info on that. 
 Just learned that these are available under a preview switch.
Can't find it anywhere in release notes, it was just silently showed up around Apr 2019.
Does your code "just work" if you use ```preview=in``` instead? Could be a good reason to just get rid of the ```rvaluerefparam``` then.
Jul 14
parent reply Mathias LANG <geod24 gmail.com> writes:
On Wednesday, 14 July 2021 at 07:26:27 UTC, Tejas wrote:
 Does your code "just work" if you use  ```preview=in``` 
 instead? Could be a good reason to just get rid of the 
 ```rvaluerefparam``` then.
Mostly. The main source of errors is that it will complain about `in` and `ref` being mixed together. The second is that, since it behaves as `scope`, if you escape parameter they might start to get diagnosed correctly. Those are the two main reasons of failure I encountered while using it / adapting projects. I've never seen a place where parameter aliasing was causing issues. Note that there are a few more things still missing for it to be complete: First, it needs to work with `foreach` (currently, `foreach` doesn't even support `scope`, so I'll do that too when I get to it), and the other is that it should probably error out with non-`extern(D|C++)` (https://github.com/dlang/dmd/pull/12242).
Jul 14
next sibling parent Mathias LANG <geod24 gmail.com> writes:
On Wednesday, 14 July 2021 at 08:00:12 UTC, Mathias LANG wrote:
 Note that there are a few more things still missing for it to 
 be complete: First, it needs to work with `foreach` (currently, 
 `foreach` doesn't even support `scope`, so I'll do that too 
 when I get to it), and the other is that it should probably 
 error out with non-`extern(D|C++)` 
 (https://github.com/dlang/dmd/pull/12242).
And storage class inference for function literals (https://issues.dlang.org/show_bug.cgi?id=9423), which will make everyone's life easier (and should allow other nice things, like allowing more `ref` in range pipelines).
Jul 14
prev sibling parent reply Tejas <notrealemail gmail.com> writes:
On Wednesday, 14 July 2021 at 08:00:12 UTC, Mathias LANG wrote:
 On Wednesday, 14 July 2021 at 07:26:27 UTC, Tejas wrote:
 Does your code "just work" if you use  ```preview=in``` 
 instead? Could be a good reason to just get rid of the 
 ```rvaluerefparam``` then.
Mostly. The main source of errors is that it will complain about `in` and `ref` being mixed together. The second is that, since it behaves as `scope`, if you escape parameter they might start to get diagnosed correctly. Those are the two main reasons of failure I encountered while using it / adapting projects. I've never seen a place where parameter aliasing was causing issues. Note that there are a few more things still missing for it to be complete: First, it needs to work with `foreach` (currently, `foreach` doesn't even support `scope`, so I'll do that too when I get to it), and the other is that it should probably error out with non-`extern(D|C++)` (https://github.com/dlang/dmd/pull/12242).
Last question: How do you _exactly_ specify that you're expecting a rvalue reference as a parameter? In other words, what is the D equivalent of this C++ code: ``` func(T&& parameter) { }```
Jul 14
parent reply Mathias LANG <geod24 gmail.com> writes:
On Wednesday, 14 July 2021 at 08:24:03 UTC, Tejas wrote:
 Last question:

 How do you _exactly_ specify that you're expecting a rvalue 
 reference as a parameter?
 In other words, what is the D equivalent of this C++ code:

 ``` func(T&& parameter) {  }```
There isn't. `in` is for const references. `-preview=rvaluerefparam` will allow you to get a mutable ref, but it simply creates a temporary at the call site (so does `-preview=in`). To my knowledge, we can't represent that in D (and we can't bind to such a definition in C++).
Jul 14
parent Tejas <notrealemail gmail.com> writes:
On Wednesday, 14 July 2021 at 14:51:41 UTC, Mathias LANG wrote:
 On Wednesday, 14 July 2021 at 08:24:03 UTC, Tejas wrote:
 Last question:

 How do you _exactly_ specify that you're expecting a rvalue 
 reference as a parameter?
 In other words, what is the D equivalent of this C++ code:

 ``` func(T&& parameter) {  }```
There isn't. `in` is for const references. `-preview=rvaluerefparam` will allow you to get a mutable ref, but it simply creates a temporary at the call site (so does `-preview=in`). To my knowledge, we can't represent that in D (and we can't bind to such a definition in C++).
Well... that's not good. Hope [DIP 1040](https://github.com/dlang/DIPs/blob/master/DIPs/DIP1040.md) gets here soon then, since rvalue references seem to be explicitly mentioned as getting added, or are there caveats in that DIP as well?
Jul 14