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

On Wednesday, 19 May 2021 at 07:36:53 UTC, evilrat wrote:

Well, ok D still got me sometimes even with that preview feature, this s**t isn't even fun...

// 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
}

// lets try this
public PxVec3 project(ref const(PxVec3) p) const {
    PxVec3 t = p;
    return t - n * distance(t); // error
}

// 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?

On Wednesday, 19 May 2021 at 08:45:22 UTC, evilrat wrote:

// 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
}

// lets try this
public PxVec3 project(ref const(PxVec3) p) const {
    PxVec3 t = p;
    return t - n * distance(t); // error
}

// 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.

On Tuesday, 13 July 2021 at 15:51:26 UTC, Tejas wrote:

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

Can't find it anywhere in release notes, it was just silently showed up around Apr 2019.

On Tuesday, 13 July 2021 at 18:20:36 UTC, evilrat wrote:

Here's the full picture from my POV:

-preview=rvaluerefparams was implemented by Walter and later documented. 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 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. I also made sure druntime/Phobos, Vibe.d, and many other packages on Buildkite 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. 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.

On Tuesday, 13 July 2021 at 18:20:36 UTC, evilrat 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.

On Wednesday, 14 July 2021 at 02:54:26 UTC, Mathias LANG wrote:

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

On Wednesday, 14 July 2021 at 07:26:27 UTC, Tejas wrote:

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

On Wednesday, 14 July 2021 at 08:00:12 UTC, Mathias LANG wrote:

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

On Wednesday, 14 July 2021 at 08:00:12 UTC, Mathias LANG 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) { }