Week 5:

Start of milestone 2.

* Move constructor semantic implemented based on the work on rvalue ref.
* A default move constructor is generated if one or more members of a struct have  move constructor.
* The move opAssign implemented as well.
* A `@move` attribute with an accompanying `__move()` intrinsic was added as an alternative to rvalue ref.

Usage example:

1. with rvalue ref

compile with the compiler switch `-preview=rvalueattribute`.
```
struct S
{
    static char[] result;
    this(@rvalue ref inout S) inout { result ~= "Mc"; }
    void opAssign(@rvalue ref inout S) inout { result ~= "Ma"; }
}

unittest
{
    S a;
    S b = cast(@rvalue ref)a;
    a = cast(@rvalue ref)b;
    assert(S.result == "McMa");
}
```

2. with the `@move` attribute

compile with the compiler switch `-preview=moveattribute`.
```
struct S
{
    static char[] result;
    this(ref inout S) @move inout { result ~= "Mc"; }
    void opAssign(ref inout S) @move inout { result ~= "Ma"; }
}

unittest
{
    S a;
    S b = __move(a);
    a = __move(b);
    assert(S.result == "McMa");
}
```

Note: the implementation is not ready yet for things like internal pointers, some interaction with the codegen is needed to eliminate the remaining blits that still exist.

On Wednesday, 23 October 2019 at 17:19:14 UTC, Suleyman wrote:
> Week 5:
>
> Start of milestone 2.
>
> [...]

The blits need to be eliminated only if the move constructor is defined, otherwise they should remain the same.

On 10/23/19 1:19 PM, Suleyman wrote:
> Week 5:
> 
> Start of milestone 2.
> 
> * Move constructor semantic implemented based on the work on rvalue ref.
> * A default move constructor is generated if one or more members of a struct have  move constructor.
> * The move opAssign implemented as well.
> * A `@move` attribute with an accompanying `__move()` intrinsic was added as an alternative to rvalue ref.
> 
> Usage example:
> 
> 1. with rvalue ref
> 
> compile with the compiler switch `-preview=rvalueattribute`.
> ```
> struct S
> {
>      static char[] result;
>      this(@rvalue ref inout S) inout { result ~= "Mc"; }
>      void opAssign(@rvalue ref inout S) inout { result ~= "Ma"; }
> }
> 
> unittest
> {
>      S a;
>      S b = cast(@rvalue ref)a;
>      a = cast(@rvalue ref)b;
>      assert(S.result == "McMa");
> }
> ```
> 
> 2. with the `@move` attribute
> 
> compile with the compiler switch `-preview=moveattribute`.
> ```
> struct S
> {
>      static char[] result;
>      this(ref inout S) @move inout { result ~= "Mc"; }
>      void opAssign(ref inout S) @move inout { result ~= "Ma"; }
> }
> 
> unittest
> {
>      S a;
>      S b = __move(a);
>      a = __move(b);
>      assert(S.result == "McMa");
> }
> ```
> 
> Note: the implementation is not ready yet for things like internal pointers, some interaction with the codegen is needed to eliminate the remaining blits that still exist.

As far as I understand this is a major language change that proceeded without a known plan, and of which likelihood to be accepted is doubtful.

This work must definitely be coordinated to the other related projects - binding rvalues to ref, move constructors, perfect forwarding, DIP 1014. We can't have different people work independently on their own vision of features that overlap 80%.

Don't we risk adding this to our growing list of projects that people invest vast amounts of talent and work, just to abandon them?

On Tuesday, 29 October 2019 at 15:20:14 UTC, RazvanN wrote:
> On Wednesday, 23 October 2019 at 17:19:14 UTC, Suleyman wrote:
>> Week 5:
>>
>> Start of milestone 2.
>>
>> [...]
>
> The blits need to be eliminated only if the move constructor is defined, otherwise they should remain the same.

Yes for the blits that have a reason to remain, like saving side effect. For redundant blits they will be simply eliminated.

On Tuesday, 29 October 2019 at 15:31:55 UTC, Andrei Alexandrescu wrote:
> On 10/23/19 1:19 PM, Suleyman
>> [...]
>
> As far as I understand this is a major language change that proceeded without a known plan, and of which likelihood to be accepted is doubtful.
>
> This work must definitely be coordinated to the other related projects - binding rvalues to ref, move constructors, perfect forwarding, DIP 1014. We can't have different people work independently on their own vision of features that overlap 80%.
>
> Don't we risk adding this to our growing list of projects that people invest vast amounts of talent and work, just to abandon them?

DIP 1014 is postblit based I was advised by Manu to work on a constructor based solution for the same reasons that lead to the copy constructor being adopted in D.

Prefect forwarding is a combination of auto ref and rvalue ref. Razvan told me he was working on perfect forwarding DIP and we talked superficially about it.
The implementation of rvalue ref which is required for a perfect forwarding solution which doesn't do a copy or move at each level is available. There is also `auto @rvalue ref` which exactly does perfect forwarding.

Binding rvalues to ref is a separate issue. Even in C++ there is rvalue ref and const ref.

The core of move semantics and perfect forwarding has been implemented. Whichever syntax is accepted in the end it will be just parser work. For example the implementation of the `@move` attribute - which is an alternative to rvalue ref just in case rvalue ref is not accepted - does actually use the rvalue ref implementation underneath, it's only parsed and mangled differently.

If I knew of something else related to move semantics that was likelier to be accepted I would have included it in this SAOC.

We surely need to collaborate. This work itself is a collaboration, I only did the implementation, the ideas are not mine. I give credits to all the contributors who shared their ideas on the initial discussion thread https://forum.dlang.org/thread/oipegxuwqmrmmzefrqcx@forum.dlang.org. We can open a thread somewhere or anybody who is interested can just contact me directly in Slack.

On Tuesday, 29 October 2019 at 21:13:16 UTC, Suleyman wrote:
> [...] I give credits to all the contributors who shared their ideas on the initial discussion thread [...]

I also give credits to my mentor Manu which explained and advised everything related related to this work.

On 30/10/2019 10:13 AM, Suleyman wrote:
> 
> We surely need to collaborate. This work itself is a collaboration, I only did the implementation, the ideas are not mine. I give credits to all the contributors who shared their ideas on the initial discussion thread https://forum.dlang.org/thread/oipegxuwqmrmmzefrqcx@forum.dlang.org. We can open a thread somewhere or anybody who is interested can just contact me directly in Slack.

For projects like this if you want a workgroup channel on the Discord server please let us know. Having as many interested parties in live chat is a great way to develop and explore ideas.

On Wednesday, 30 October 2019 at 02:18:12 UTC, rikki cattermole wrote:
> On 30/10/2019 10:13 AM, Suleyman wrote:
>> [...]
>
> For projects like this if you want a workgroup channel on the Discord server please let us know. Having as many interested parties in live chat is a great way to develop and explore ideas.

This is a good idea.

Week 6:

A partial solution was implemented for issue https://issues.dlang.org/show_bug.cgi?id=20321.
A more complete solution is still work in progress.

Week 7:

More progress on issue 20321. Made a second pull request[1].
Also audited all temporaries which are created in the glue layer of DMD and compiled a report about it[2]. This narrowed down the problem significantly. The report contains links to test cases and links to the pull request that has the fix if available.

[1] https://github.com/dlang/dmd/pull/10539
[2] https://gist.github.com/SSoulaimane/f87a9f86dc8808eab8ac787e237b47b2