Preview features status?

[Tejas]

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 :)