Rvalue references, move constructors and move assignment are concepts that I'm very excited about as future additions to D. Do we have a date for the next community review or -preview flag? We've been trying to have rvalue references for years now... would be nice to finally see a real implementation of some kind.

Thank you for your time!

On Monday, 2 August 2021 at 17:27:37 UTC, Tejas wrote:

Who's 'we'? Some people have; I've advocated against them, but am all in favor of move constructors and assignments.

Define 'real' implementation - proof-of-concepts exist for ~2 years:

• https://github.com/dlang/dmd/pull/10383
• https://github.com/dlang/dmd/pull/10426

On Monday, 2 August 2021 at 17:37:44 UTC, kinke wrote:

Didn't Walter(and one more) write the very first proof-of-concept and it got added as -preview=rvaluerefparams back in April 2019? I assume it was because people DID want them?

No, they're not the same as C++
https://forum.dlang.org/post/qhynxxrdsaahxvoglztx@forum.dlang.org

On Monday, 2 August 2021 at 17:27:37 UTC, Tejas wrote:

DIP reviews do not follow a schedule. They can only go forward when a DIP author is ready to do so and can be available to respond to feedback. 1040 will move forward when Max is ready.

On Tuesday, 3 August 2021 at 04:25:15 UTC, Mike Parker wrote:

Ah... cool.

Thank you very much.

On Monday, 2 August 2021 at 17:49:56 UTC, Tejas wrote:

-preview=rvaluerefparams is a bit different - it is about simply allowing rvalues to be passed to ref parameters, but it doesn't involve adding T&& as a type constructor to the type system, what I would call real rvalue references. In other words, in C++ you can differentiate between an lvalue reference (T&) and an rvalue one (T&&) via function overloading, but in D you can't. I think what @kinke is saying is that we don't need the whole complexity that T&& brings to C++ as we can achieve 95% of its usefulness with move constructors and move assignment operators.

On Tuesday, 3 August 2021 at 07:53:20 UTC, Petar Kirov [ZombineDev] wrote:

I know they're not real(see my original post's 2nd last sentence), but I was working out how to transpile C++ and without being able to represent rvalue refs, it's going to be impossible.
How can you hope to accurately represent t&& without rvalue refs?

How will I accurately transpile

auto func(t)
auto func(t&)
auto func(t&&)

set of overloads without rvalue refs?
I could play around with typedefs and somehow manage(perhaps), but it would be a lie and hurt performance non-trivially.

On Tuesday, 3 August 2021 at 08:29:15 UTC, Tejas wrote:

Perhaps look at how rvalue references are implemented under-the-hood in existing C++-to-native-code compilers, and use a similar technique in your C++-to-D compiler? After all, there is no such thing as an "rvalue reference" in assembly either.

Of course, this means you will have to do some semantic analysis on the C++ code to figure out when a parameter is being passed by rvalue reference, and translate it accordingly.

On Tuesday, 3 August 2021 at 11:51:38 UTC, Paul Backus wrote:

Sorry, but that sounds like saying implementing a generational garbage collector should be possible since assembly doesn't have a notion of "garbage collection".

Even zombinedev said above that construct t&& itself is not supported by the type system of D.

If what you're saying was possible then Walter and Manu needn't have bothered with preview=rvaluerefparam since D compiles to native code, which can represent all constructs.

Another example: template constraints vs concepts. No matter what, we simply cannot transform constraints in such a way that we won't have to write if in the very first line of template definition. Sure, we might be able to hide it behind an alias, or function,@attribute or whatever; but you will have to write that if, because D simply doesn't support writing template constraints in another way(and mixins don't allow that syntax-changing "monkey business"(I don't disagree that the label is wrong, btw)). Atlia went the attributes way and made this:
https://github.com/atilaneves/concepts
But you still require to put the if in your template.

Lastly, I urge you as well to see this post that I linked previously

https://forum.dlang.org/post/qhynxxrdsaahxvoglztx@forum.dlang.org

Even Mathias is agreeing that there is no way to represent this (that he knows of).

I hope I'm not coming off as snarky. I too don't like talking about this again and again like a broken record but I also don't think there's a way to represent them without a language change. I know about this, but that's like saying we don't need @nogc exceptions because this exists.