week 8:
  - finished the semantics of the default move opAssign
    - the default move opAssign is generated if:
      1. struct the move constructor
      2. one of struct fields defines the move opAssign

This marks the end of milestone 2 for which the objective was to implement user controlled move semantics in D.

Accomplished tasks:
- Implementation of the move constructor and move opAssign using rvalue ref or alternatively using the @move attribute.
- Fixing most cases of issue 20321 where the compiler copies objects without calling the copy or move constructor.

The following tasks will be continued after the SAOC period because they didn't fit the schedule of this milestone.
- Implement move semantics in druntime functions that perform array operations.
- Solve the two remaining cases of issue 20321.

Week 9:
  - fixed issue 20235[1] which was blocking std::string.
  - fixed issue 20413[2] which was blocking std::pair.


[1] https://issues.dlang.org/show_bug.cgi?id=20235
[2] https://issues.dlang.org/show_bug.cgi?id=20413

Week 11:

GCC and Clang versions of std::vector were ported. Like the windows port version there is not range API yet, only arrays are accepted, for this reason the bitmap packed vector<bool> is not yet implemented. The Range interface is on the TODO list for the future.

On Wednesday, 11 December 2019 at 16:56:40 UTC, Suleyman wrote:
> Week 11:
>
> GCC and Clang versions of std::vector were ported. [...]

Pull request to `core.stdcpp.vector` https://github.com/dlang/druntime/pull/2866.

On Wednesday, 11 December 2019 at 16:56:40 UTC, Suleyman wrote:
> Week 11:
>
> GCC and Clang versions of std::vector were ported. Like the windows port version there is not range API yet, only arrays are accepted, for this reason the bitmap packed vector<bool> is not yet implemented. The Range interface is on the TODO list for the future.

Could you expand a bit on this? Does it mean I can call a C++ function taking std::vector<double> as an argument with a double[] allocated on the D side?

On Wednesday, 11 December 2019 at 17:02:47 UTC, bachmeier wrote:
> On Wednesday, 11 December 2019 at 16:56:40 UTC, Suleyman wrote:
>> Week 11:
>>
>> GCC and Clang versions of std::vector were ported. Like the windows port version there is not range API yet, only arrays are accepted, for this reason the bitmap packed vector<bool> is not yet implemented. The Range interface is on the TODO list for the future.
>
> Could you expand a bit on this? Does it mean I can call a C++ function taking std::vector<double> as an argument with a double[] allocated on the D side?

D doesn't have implicit constructors for function parameters otherwise you could do what you've described.

But you can currently construct a vector and assign it from an array, it just won't do it automatically for function arguments for the reason mentioned.

Example:
```
import core.stdcpp.vector;

// construct
vector!double v = [1.0, 2.1];

double[] a = [];
// assign
v = a;

void f(vector!double);
f(a); // error
```

On Wednesday, 11 December 2019 at 17:15:26 UTC, Suleyman wrote:
> On Wednesday, 11 December 2019 at 17:02:47 UTC, bachmeier wrote:
>> On Wednesday, 11 December 2019 at 16:56:40 UTC, Suleyman wrote:
>>> Week 11:
>>>
>>> GCC and Clang versions of std::vector were ported. Like the windows port version there is not range API yet, only arrays are accepted, for this reason the bitmap packed vector<bool> is not yet implemented. The Range interface is on the TODO list for the future.
>>
>> Could you expand a bit on this? Does it mean I can call a C++ function taking std::vector<double> as an argument with a double[] allocated on the D side?
>
> D doesn't have implicit constructors for function parameters otherwise you could do what you've described.
>
> But you can currently construct a vector and assign it from an array, it just won't do it automatically for function arguments for the reason mentioned.
>
> Example:
> ```
> import core.stdcpp.vector;
>
> // construct
> vector!double v = [1.0, 2.1];
>
> double[] a = [];
> // assign
> v = a;
>
> void f(vector!double);
> f(a); // error
> ```

Okay. That's reasonable. Does v = a copy or can we reuse a.ptr with your implementation? Keep in mind that I don't know much about std::vector or the work you're doing.

On Wednesday, 11 December 2019 at 17:48:24 UTC, bachmeier wrote:
>> [...]
>
> Okay. That's reasonable. Does v = a copy or can we reuse a.ptr with your implementation? Keep in mind that I don't know much about std::vector or the work you're doing.

If you pass it a slice then it has to copy, and the reason being is that  `vector!double` is short for `vector!(double, allocator!double)`, notice it has an allocator therefore it can't reuse the a pointer if the allocator is not the same.

Even if hypothetically there was no allocator problem then a move operation - which is what you've described as reusing the slice pointer - can only be done if the constructor/opAssign of the vector knows that the slice is an rvalue (for example an array literal is an rvalue, or the result of an explicit move operation is also an rvalue) and I don't know of any way to declare a slice of rvalues right now. I will add a slice of rvalues as a type to my rvalue ref implementation (which will be documented and announced with a DIP in the next milestone). I was hesitant at first to allow slices of rvalues, but after porting std::vector I came across various move strategies among which was move iterators and since used slices instead, I found that I couldn't declare a move construtor/opAssign for slices, and I didn't, this is one of the lacking parts right now in the array API of vector, if you pass a slice it always has to copy no matter what.

Week 12:

The remaining parts of std::string were implemented. These are:

* atomic ref counting in the GCC version.
* growing with resize().
* reserve(), shrink_to_fit(), insert(), replace(), and swap().

link to `core.stdcpp.string` pull request https://github.com/dlang/druntime/pull/2878.