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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021