On Tue, Sep 3, 2019 at 5:35 PM Exil via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> 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?

Yes, this thing. The excessive memcpy's at every level of the callstack are a major problem.

On Wednesday, 4 September 2019 at 00:33:06 UTC, Exil wrote:
> How would it work with multi-function passing though? With a rvalue reference, you are effectively just passing around a reference.

That aspect of rvalue ref is simply assigning to a temporary then passing it by ref.

C++ example: https://cpp.godbolt.org/z/PRmkjd
D equivalent: https://d.godbolt.org/z/idPqIN

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

We don't need to expose rvalue ref as a language feature to do move semantics. The example with the attribute `@move` works just fine. Onl the first parameter is an rvalue ref.

On Wednesday, 4 September 2019 at 00:33:06 UTC, Exil wrote:
> 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?

Yes, by changing the ABI details to the C++ way in this regard, making move/forward intrinsics and detecting them in argument expressions. Laid out earlier in this thread in https://forum.dlang.org/post/jogsaeqxouxaeflmgzcc@forum.dlang.org. We don't need rvalue refs in the language for that at all, just use a value parameter - rvalue args will be passed by ref under the hood, just like explicitly moved lvalue args.

On Wednesday, 4 September 2019 at 08:21:05 UTC, Suleyman 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

I want to tell something to u, Manu, WB... "u do something wrong with lang"

let's see C++ copy constructor
> Point( const Point& rhs ) { ... } // const ref to A. that all

let's D copy constructor
> this( ref return scope const Point rhs ) { ... } // const.. ref to.. WTF?

I understand that u can explain every word in such construction but
for others it looks like "3.14dec" - u see here PI and something.. decimal? why? what is this mean?
ok. ask any Russian friend/familiar, he will tell u that this means "big fucked up" in rude form. wait! what?! how?!
and same way I read/see copy constructors in D.
ok. show such construction to somebody who knows about copy constructors but not D guru and ask him what does he think about it?

another side is move constructor. C++ again:
> Data( Data&& rhs ) { ... } // even less chars than for copy.
         // && - either logical AND or move semantics. u can't mistake.
D?
> this( @rvalue Data rhs ) @move { ... }
3.14dec!
it even doesn't like to copy constructor - related entities.

most people I think come to D from C++ or they tried C++ and faced with something incomprehensible, ambiguous, complex.
(it seems to me that the templates are too sophisticated, and in D templates are understandable with constraints it even easier.)
and they come to D cuz many people said on any forums "try to use D that has advantages over <lang>".
and people try to write easy entity like "Point" and see.. this - copy/move..
it looks like fraud.
its not easy to understand, u just can not step into D by soft step, u should read half specification to understand clear, simple things that is not clear and looks not simple.

please hold things easy. I don't know how, but keep a easy way.

On Wednesday, 4 September 2019 at 09:22:09 UTC, a11e99z wrote:
> On Wednesday, 4 September 2019 at 08:21:05 UTC, Suleyman 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
>

copy can be
> this( Point rhs ) @copy { ... }
move can be
> this( Point rhs ) @move { ... }
or even without args cuz they are known
(need to think about it cuz C++ supports slicing values and D want to interoperate with C++ code)

human see construction:
> this() @copy { ... } // do we really need this() here?
and let compiler see here comfortable for it:
> this( ref return scope const Point rhs ) { ... }

OT:

as I told before D needs attrs that relates to the compiler.
@copy @move @nogc @safe @nodiscard ...
and @inline/@noinline as alias for "pragma( inline, val )" cuz meaning of this pragma is same as compiler attr but looks like something foreign/alien - again one meaning in 2+ unclear forms.

in the future more than a dozen attributes will appear:
@inline is useful
@nodiscard is useful
@likely is useful

and need to do something with attrs to cuz code like
> @inline @nodiscard Complicated func( Args... ) @nogc nothrow { .. }
looks like a mess/crap

attrs in C#/Rust looks as separate clear constructions that u can ignore by eyes when see code for meaning. such(above) code u should read word by word, ur eye just can ignore any parts

On Wednesday, 4 September 2019 at 09:22:09 UTC, a11e99z wrote:
> On Wednesday, 4 September 2019 at 08:21:05 UTC, Suleyman wrote:
>>> [...]
>
> I want to tell something to u, Manu, WB... "u do something wrong with lang"
>
> [...]
That's not mandatory. You can simply define it as:

this(ref Point rhs) {}

It's just that it is good practice to use return scope.

> I understand that u can explain every word in such construction but
> for others it looks like "3.14dec" - u see here PI and something.. decimal? why? what is this mean?
> ok. ask any Russian friend/familiar, he will tell u that this means "big fucked up" in rude form. wait! what?! how?!
> and same way I read/see copy constructors in D.
> ok. show such construction to somebody who knows about copy constructors but not D guru and ask him what does he think about it?
>
> [...]

On Wednesday, 4 September 2019 at 00:33:06 UTC, Exil wrote:
> 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?

I think you scored a valid point here. This is where having rvalue ref comes in handy. In C++ assigning an rvalue ref to an lvalue does move not copy.

C++ example:
```
void fun(T&& arg)
{
    T var = arg; // move not copy
}
```

D:
```
void fun(ref T arg)
{
    T var = arg; // copy not move
}
```

Ref doesn't preserve move information about the source. If we go the `@rvalue ref` way then we can achieve something similar.

On Wednesday, 4 September 2019 at 00:58:44 UTC, Manu wrote:
> 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.

If you can get the move constructor and move assignment in addition to an intrinsic function for moving lvalues to rvalues then you can do move semantics without rvalue ref.

unique_ptr in C++ doesn't move itself magically. You have to eplicitly move it by calling `move()`. Example: https://cpp.godbolt.org/z/8jVONg.
You can do that with the machinery provided in the POC without rvalue ref.

On Wednesday, 4 September 2019 at 09:22:09 UTC, a11e99z wrote:
> [...]
> let's see C++ copy constructor
>> Point( const Point& rhs ) { ... } // const ref to A. that all
>
> let's D copy constructor
>> this( ref return scope const Point rhs ) { ... } // const.. ref to.. WTF?

I feel ya.

> another side is move constructor. C++ again:
>> Data( Data&& rhs ) { ... } // even less chars than for copy.
>          // && - either logical AND or move semantics. u can't mistake.
> D?
>> this( @rvalue Data rhs ) @move { ... }
> 3.14dec!
> it even doesn't like to copy constructor - related entities.

relax, it's going to be either way with `@rvalue` or with `@move` not with both.

> most people I think come to D from C++ or they tried C++ and faced with something incomprehensible, ambiguous, complex.
> (it seems to me that the templates are too sophisticated, and in D templates are understandable with constraints it even easier.)
> and they come to D cuz many people said on any forums "try to use D that has advantages over <lang>".
> and people try to write easy entity like "Point" and see.. this - copy/move..
> it looks like fraud.
> its not easy to understand, u just can not step into D by soft step, u should read half specification to understand clear, simple things that is not clear and looks not simple.
>
> please hold things easy. I don't know how, but keep a easy way.

Well C++ rvalue ref is not easy to understand either. If we go the @rvalue ref way it's going to be the same. If we go the @move way then if you can understand the copy constructor, the @move attributes simply denotes the move version of the copy constructor. If you don't understand the difference between move and copy then you don't need to use it and it won't come in your way until you do.