September 02, 2019
On Mon., 2 Sep. 2019, 6:10 pm Suleyman via Digitalmars-d, < digitalmars-d@puremagic.com> wrote:

> I updated the POC.
>
> You can now declare the move constructor & move opAssing like the following:
>
> ```
> struct S
> {
>      this(ref S) @move {}     // move constructor
>      opAssign(ref S) @move {} // move opAssign
> }
> ```
>
> Or with rvalue ref:
>
> ```
> struct S
> {
>      this(@rvalue ref S) {}     // move constructor
>      opAssign(@rvalue ref S) {} // move opAssign
> }
> ```
>
> All implementations use rvalue ref internally. It's just a matter of exposing in the language it or not.
>

Nice work!
I definitely think it needs to be on the argument and not on the method, or
it can't be used on functions that take more than one argument.

>


September 03, 2019
On Tuesday, 3 September 2019 at 01:50:20 UTC, Manu wrote:
> On Mon., 2 Sep. 2019, 6:10 pm Suleyman via Digitalmars-d, < digitalmars-d@puremagic.com> wrote:
>
>> I updated the POC.
>> [...]
>>
>
> Nice work!
> I definitely think it needs to be on the argument and not on the method, or
> it can't be used on functions that take more than one argument.

Nice job!

I agree with Manu.
September 03, 2019
On Thursday, 29 August 2019 at 19:04:45 UTC, Manu wrote:
> On Thu, Aug 29, 2019 at 2:45 AM Atila Neves via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> On Thursday, 29 August 2019 at 04:38:03 UTC, Manu wrote:
>> > On Wed, Aug 28, 2019 at 8:45 PM Suleyman via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> >> [...]
>> >
>> > It's a _part_ of perfect forwarding; the part that allows a
>> > function
>> > to receive forwarded arguments.
>> > The other part is a `forward` implementation passes them
>> > forward (and
>> > actually works), and that depends on a `move` implementation
>> > that
>> > works.
>>
>> What's wrong with the current `move` and `forward` implementations?
>
> Open core.lifetime and look at the text. If you're not terrified, then
> you're a braver man than me.

I've opened it before. I don't know how much of it is accidental complexity. The last time, I assumed none of it was.

> Then also consider that the file has edge cases and bugs which I've
> run into on numerous occasions. We don't have move semantics, we have
> copy-elision and a bunch of hacks that unnecessarily call memcpy a lot
> of times (and don't actually work).
> Our move semantics are slow (lots of copying, not actually moving),
> and occasionally broken.

So you've mentioned before. It'd be really helpful to have a list of those bugs and edge cases.

>
> For reference, here's the C++ implementation of that entire file:
>
> template <class T>
> T&& move(T& val) { return (T&&)val; }
>
> Our implementation would/should be similar.

The C++ implementation is simple because the language is not by having rvalue references.

September 03, 2019
On Tue, Sep 3, 2019 at 7:40 AM Atila Neves via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Thursday, 29 August 2019 at 19:04:45 UTC, Manu wrote:
> > On Thu, Aug 29, 2019 at 2:45 AM Atila Neves via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>
> >> On Thursday, 29 August 2019 at 04:38:03 UTC, Manu wrote:
> >> > On Wed, Aug 28, 2019 at 8:45 PM Suleyman via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >> >> [...]
> >> >
> >> > It's a _part_ of perfect forwarding; the part that allows a
> >> > function
> >> > to receive forwarded arguments.
> >> > The other part is a `forward` implementation passes them
> >> > forward (and
> >> > actually works), and that depends on a `move` implementation
> >> > that
> >> > works.
> >>
> >> What's wrong with the current `move` and `forward` implementations?
> >
> > Open core.lifetime and look at the text. If you're not
> > terrified, then
> > you're a braver man than me.
>
> I've opened it before. I don't know how much of it is accidental complexity. The last time, I assumed none of it was.

You have to look no further than a call to `memcpy` in any of those functions to know it's all terrible.

> > Then also consider that the file has edge cases and bugs which
> > I've
> > run into on numerous occasions. We don't have move semantics,
> > we have
> > copy-elision and a bunch of hacks that unnecessarily call
> > memcpy a lot
> > of times (and don't actually work).
> > Our move semantics are slow (lots of copying, not actually
> > moving),
> > and occasionally broken.
>
> So you've mentioned before. It'd be really helpful to have a list of those bugs and edge cases.

I fix them as soon as finding them, but that still doesn't help that it's a mad and terrible hack, it's just one that gets closer to working.

> > For reference, here's the C++ implementation of that entire file:
> >
> > template <class T>
> > T&& move(T& val) { return (T&&)val; }
> >
> > Our implementation would/should be similar.
>
> The C++ implementation is simple because the language is not by having rvalue references.

I don't think that's the case. Evidently, C++'s solution is a lot
simpler than our solution, language included. I mean, we can't move at
all.
'Simple' is only better if it actually works. If it's simple and
doesn't work, then it's not better (see, copy-ctor replacing postblit
for example).
September 03, 2019
On Tuesday, 3 September 2019 at 11:20:43 UTC, Eduard Staniloiu wrote:
> On Tuesday, 3 September 2019 at 01:50:20 UTC, Manu wrote:
>> On Mon., 2 Sep. 2019, 6:10 pm Suleyman via Digitalmars-d, < digitalmars-d@puremagic.com> wrote:
>>
>>> I updated the POC.
>>> [...]
>>>
>>
>> Nice work!
>> I definitely think it needs to be on the argument and not on the method, or
>> it can't be used on functions that take more than one argument.
>
> Nice job!
>
> I agree with Manu.

I'm still demanding a use case for rvalue ref other than move semantics.
September 03, 2019
On Tuesday, 3 September 2019 at 01:50:20 UTC, Manu wrote:
> it can't be used on functions that take more than one argument.

I'm still demanding a use case for rvalue ref other than for move semantics.

September 03, 2019
On Tue, Sep 3, 2019 at 2:45 PM Suleyman via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Tuesday, 3 September 2019 at 01:50:20 UTC, Manu wrote:
> > it can't be used on functions that take more than one argument.
>
> I'm still demanding a use case for rvalue ref other than for move semantics.

That's it; move semantics. That's not a minor thing...
Why?
September 04, 2019
On Tuesday, 3 September 2019 at 23:51:43 UTC, Manu wrote:
> On Tue, Sep 3, 2019 at 2:45 PM Suleyman via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> I'm still demanding a use case for rvalue ref other than for move semantics.
>
> That's it; move semantics. That's not a minor thing...
> Why?

Because just detecting move-construction/-assignment/'argument moval' can get away with special identifiers for constructor/assignment operator or some special @move UDA, as Suleyman has proposed so far, instead of fully extending the language by rvalue refs, with mangling additions and new overload rules etc.

It's clear that this would restrict C++ interop, but that's the point - do we want to adopt the C++ approach fully, or keep things simple & tidy at the expense of not being able to represent C++ functions with rvalue refs (except for move constructor and assignment op)?
September 04, 2019
On Wednesday, 4 September 2019 at 00:16:06 UTC, kinke wrote:
> On Tuesday, 3 September 2019 at 23:51:43 UTC, Manu wrote:
>> On Tue, Sep 3, 2019 at 2:45 PM Suleyman via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>> I'm still demanding a use case for rvalue ref other than for move semantics.
>>
>> That's it; move semantics. That's not a minor thing...
>> Why?
>
> Because just detecting move-construction/-assignment/'argument moval' can get away with special identifiers for constructor/assignment operator or some special @move UDA, as Suleyman has proposed so far, instead of fully extending the language by rvalue refs, with mangling additions and new overload rules etc.
>
> It's clear that this would restrict C++ interop, but that's the point - do we want to adopt the C++ approach fully, or keep things simple & tidy at the expense of not being able to represent C++ functions with rvalue refs (except for move constructor and assignment op)?

How would it work with multi-function passing though? With a rvalue reference, you are effectively just passing around a reference, until the contents of the value are moved. So you can pass it through N functions and it won't ever to do a move/copy.

Would you effectively be relying on the compiler to optimize out the un-necessary moves, or would they be unavoidable, as they effectively are now?
September 03, 2019
On Tue, Sep 3, 2019 at 5:20 PM kinke via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Tuesday, 3 September 2019 at 23:51:43 UTC, Manu wrote:
> > On Tue, Sep 3, 2019 at 2:45 PM Suleyman via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >> I'm still demanding a use case for rvalue ref other than for move semantics.
> >
> > That's it; move semantics. That's not a minor thing...
> > Why?
>
> Because just detecting move-construction/-assignment/'argument moval' can get away with special identifiers for constructor/assignment operator or some special @move UDA, as Suleyman has proposed so far, instead of fully extending the language by rvalue refs, with mangling additions and new overload rules etc.
>
> It's clear that this would restrict C++ interop, but that's the point - do we want to adopt the C++ approach fully, or keep things simple & tidy at the expense of not being able to represent C++ functions with rvalue refs (except for move constructor and assignment op)?

Move semantics aren't a feature of the move constructor, they are USED
BY the move constructor.
You can move an argument to any function. Consider a unique_ptr, which
can only move. It would be impossible to pass a unique_ptr to any
other function than the move constructor itself.
1 2 3 4 5 6 7 8 9 10 11 12