On Saturday, 7 September 2019 at 21:41:16 UTC, kinke wrote:
> It's not because of dangerousness or such, but firstly because I think pure rvalue refs (disallowing lvalue args) are used extremely seldomly, and secondly because I want to avoid further syntactic complexity. We have ref, auto ref, scope ref, return ref, now we're discussing @rvalue ref...

That still doesn't justify hiding it under auto ref. If it is rarely used then even if you add the attribute to the language it will be rarely used. Instead of explaining the new @rvalue keyword, we will be explaining the unnamed auto ref expansion. There is a difference between being naturally rarely used and inconveniencing people off of it.

When you have a bloat of names then fix the naming conventions. Hiding this under existing stuff like auto ref is like brushing it under the carpet.

On Sat, Sep 7, 2019 at 2:45 PM kinke via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Saturday, 7 September 2019 at 21:09:45 UTC, Suleyman wrote:
> > On Saturday, 7 September 2019 at 12:04:49 UTC, kinke wrote:
> >> ```
> >> void foo()(auto ref S s)
> >>   if (__traits(isRvalueRef, s));
> >> ```
> >
> > This is a really just an awkward way of doing `void foo(@rvalue
> > ref S s)`.
> >
> >> I'd prefer the latter value-view, as that's compatible with current semantics.
> >
> > At this point you have essentially admitted rvalue ref in the language but you're fighting to keep it hidden from the user as much as possible.
>
> Yes.
>
> > I personally don't thing rvalue ref is that much dangerous to be kept away from the programmers hand. Hiding rvalue ref under auto ref is simply discouraging people from using it.
>
> It's not because of dangerousness or such, but firstly because I think pure rvalue refs (disallowing lvalue args) are used extremely seldomly, and secondly because I want to avoid further syntactic complexity. We have ref, auto ref, scope ref, return ref, now we're discussing @rvalue ref...

My experience with D has shown me time and time again, when something
exists in the language that has no actual language to interact with
it, that is the *real* complexity in D.
Everything that sucks the most in D is the things that have no proper
expression in the language.
D is a power-user language, and that ship sailed a very long time ago.
We still have D's current default move semantics, and they will not
disappear; your average user will not be affected by this. For the
power user that needs it though, direct expression is *MUCH* simpler
than making them jump through hoops to interact with a language
feature indirectly.
We've done that a lot before, and it's a disaster every single time.

On Sat, Sep 7, 2019 at 2:45 PM kinke via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> We have ref, auto ref, scope ref, return
> ref, now we're discussing @rvalue ref...

These concepts are mostly orthogonal. `auto ref` is an umbrella over
`ref` and TBD @`rvalue ref`. `scope` is orthogonal, and `return` too,
although that's slightly related to `scope`. These things work
together, but their interaction is not complexity; the fact they
interact naturally is a consequence of simple design. Complex design
is when they DON'T interact naturally, and edge cases emerge or
hard-coded interactions which are individually speced exist.
We haven't shown that here. As I see it, the conversation that's
avoiding `@rvalue ref` is the stuff that's just trying to work
semantics into special-case rule definitions, whereas `@rvalue ref` is
the purest definition that happens to exist orthogonally to all this
stuff, and naturally interacts with existing language to produce all
the desired semantics.

On Saturday, 7 September 2019 at 21:41:16 UTC, kinke wrote:
> We have ref, auto ref, scope ref, return ref, now we're discussing @rvalue ref...

At this point we should consider having an rvalue pointer type. We have concluded that preserving the rvalueness of a ref (which is simply a pointer) is valuable, we could take it further and save the rvalueness in pointer types as well. I find it strange that you cant declare a pointer to an rvalue ref in C++ for example `int&&*`.

On Sat, Sep 7, 2019 at 5:50 PM Suleyman via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Saturday, 7 September 2019 at 21:41:16 UTC, kinke wrote:
> > We have ref, auto ref, scope ref, return ref, now we're discussing @rvalue ref...
>
> At this point we should consider having an rvalue pointer type. We have concluded that preserving the rvalueness of a ref (which is simply a pointer) is valuable, we could take it further and save the rvalueness in pointer types as well. I find it strange that you cant declare a pointer to an rvalue ref in C++ for example `int&&*`.

I think the reason is that, in C++, pointers would be eliminated from the language if they could get away with the deviation from legacy. In C++, ref's are part of the type, and this works immeasurably better than this 'storage class' idea we have in D. So when they added rval ref's, they extended the expression for pointers that they would prefer you invest in, which is references in general.

I think the advantage of using references for rvalues, is that you
can't assign references, you can't store them off somewhere, which is
the implication that you take from being handed a pointer.
If we introduce rval pointers, then you'd be able to assign them, make
struct members, all that stuff, which you can't do with ref's.

I find it a bit weird to think about an rvalue pointer, because the natural conclusion is that I can create one on the stack and freely assign to/from it, or as a member of a struct... that gets strange very quickly.

On Sunday, 8 September 2019 at 00:46:22 UTC, Suleyman wrote:
> At this point we should consider having an rvalue pointer type. We have concluded that preserving the rvalueness of a ref (which is simply a pointer) is valuable, we could take it further and save the rvalueness in pointer types as well. I find it strange that you cant declare a pointer to an rvalue ref in C++ for example `int&&*`.

This can be achieved with either an rvalue type modifier like const and shared or with a type suffix like &. Then parameters could be declared as a ref or a pointer to an rvalue'ed type.

On Sunday, 8 September 2019 at 01:04:35 UTC, Manu wrote:
> I think the reason is that, in C++, pointers would be eliminated from the language if they could get away with the deviation from legacy. In C++, ref's are part of the type, and this works immeasurably better than this 'storage class' idea we have in D. So when they added rval ref's, they extended the expression for pointers that they would prefer you invest in, which is references in general.

There is pointer to pointer but there is no ref to ref. That is an unjustified limitation. Just because certain aspects of pointers can be replaced by doesn't mean ref is good and pointer is bad.

> I think the advantage of using references for rvalues, is that you
> can't assign references, you can't store them off somewhere, which is
> the implication that you take from being handed a pointer.

I'm not sure what you mean. You certainly can store rvalue ref in C++ everywhere, even inside structs. And when you take a pointer it's just the same underground except that you lose type information unjustifiably.

> If we introduce rval pointers, then you'd be able to assign them, make
> struct members, all that stuff, which you can't do with ref's.

You can already do all of that in C++ https://cpp.godbolt.org/z/ZfdOeu

> I find it a bit weird to think about an rvalue pointer, because the natural conclusion is that I can create one on the stack and freely assign to/from it, or as a member of a struct... that gets strange very quickly.

Ref in C++ is unjustifiably limited. And saving rvalueness has nothing to do in the ref vs pointer battle.

On Sat, Sep 7, 2019 at 6:35 PM Suleyman via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 8 September 2019 at 01:04:35 UTC, Manu wrote:
> > I think the reason is that, in C++, pointers would be eliminated from the language if they could get away with the deviation from legacy. In C++, ref's are part of the type, and this works immeasurably better than this 'storage class' idea we have in D. So when they added rval ref's, they extended the expression for pointers that they would prefer you invest in, which is references in general.
>
> There is pointer to pointer but there is no ref to ref. That is an unjustified limitation. Just because certain aspects of pointers can be replaced by doesn't mean ref is good and pointer is bad.
>
> > I think the advantage of using references for rvalues, is that
> > you
> > can't assign references, you can't store them off somewhere,
> > which is
> > the implication that you take from being handed a pointer.
>
> I'm not sure what you mean. You certainly can store rvalue ref in C++ everywhere, even inside structs. And when you take a pointer it's just the same underground except that you lose type information unjustifiably.
>
> > If we introduce rval pointers, then you'd be able to assign
> > them, make
> > struct members, all that stuff, which you can't do with ref's.
>
> You can already do all of that in C++ https://cpp.godbolt.org/z/ZfdOeu
>
> > I find it a bit weird to think about an rvalue pointer, because the natural conclusion is that I can create one on the stack and freely assign to/from it, or as a member of a struct... that gets strange very quickly.
>
> Ref in C++ is unjustifiably limited. And saving rvalueness has nothing to do in the ref vs pointer battle.

I understand where you're coming from, but this opens up an enormous can of worms and widens the scope of the conversation enormously... I think we have about a 15% chance of being successful with an @rvalue ref proposal as is, and I feel like if we try and expand that to a type-constructor and make it applicable to pointers, we fall to around 0.01% change of success.

I spend too much time and energy here as it is. I would advise against doing something that cuts your chances of success by 1000x, and I couldn't personally make the time to argue in favour :/

On Sunday, 8 September 2019 at 01:46:11 UTC, Manu wrote:
> I understand where you're coming from, but this opens up an enormous can of worms and widens the scope of the conversation enormously... I think we have about a 15% chance of being successful with an @rvalue ref proposal as is, and I feel like if we try and expand that to a type-constructor and make it applicable to pointers, we fall to around 0.01% change of success.
>
> I spend too much time and energy here as it is. I would advise against doing something that cuts your chances of success by 1000x, and I couldn't personally make the time to argue in favour :/

I didn't intend to just copy C++ blindly. If we did we wouldn't have D we would still be using C++. If it's a complete solution it has more chance to make it in D. If it's just a knock off of C++ it probably won't.

On Sunday, 8 September 2019 at 02:06:54 UTC, Suleyman wrote:
> On Sunday, 8 September 2019 at 01:46:11 UTC, Manu wrote:
>> [...]
>
> I didn't intend to just copy C++ blindly. If we did we wouldn't have D we would still be using C++. If it's a complete solution it has more chance to make it in D. If it's just a knock off of C++ it probably won't.

Copy constructors got in...