On Sunday, 8 September 2019 at 02:56:00 UTC, Les De Ridder wrote:
> Copy constructors got in...

Ideally the fact that copy constructors are build upon implicit constructors should have been considered. But I'm still fine with that. I don't think whether it is marked implicit or not should make a difference for copy and move constructors.

On Sat, Sep 7, 2019 at 7:10 PM Suleyman via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> 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.

Actually, why doesn't it naturally work with pointers?
The same way `scope` applied to pointers or ref's or anything with
references, shouldn't `@rvalue` have the same attribution semantics as
`scope` for instance?
I guess you're right; if it didn't naturally apply to pointers the
same way `scope` does, it would be a weird kind of edge case.
The application of the attribute should behave the same as `scope`.

On Sunday, 8 September 2019 at 03:21:06 UTC, Manu wrote:
> Actually, why doesn't it naturally work with pointers?
> The same way `scope` applied to pointers or ref's or anything with
> references, shouldn't `@rvalue` have the same attribution semantics as
> `scope` for instance?
> I guess you're right; if it didn't naturally apply to pointers the
> same way `scope` does, it would be a weird kind of edge case.
> The application of the attribute should behave the same as `scope`.

I didn't mean it should be like scope. I meant it should be like const an shared. For example the address of an rvalue ref is pointer to an rvalue type `is(typeof(&arg) == rvalue(S)*)` this way rvalueness is preserved when the adress is taken, thus you can have something like `rvalue(S)***`. Dereferencing such such pointers returns an rvalue ref thus automatically calls the move constructor instead of the copy constructor.

On Sunday, 8 September 2019 at 18:49:51 UTC, Suleyman wrote:
> [...]

Then having `cast(rvalue)` instead of the `__move` intrinsic would make perfect sense in the language.

On Sun, Sep 8, 2019 at 12:05 PM Suleyman via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 8 September 2019 at 18:49:51 UTC, Suleyman wrote:
> > [...]
>
> Then having `cast(rvalue)` instead of the `__move` intrinsic would make perfect sense in the language.

Right, you wanna make it a type constructor.
This should be the case also for ref and scope too... but you will
*never* get that past Walter.
This thing you describe is the single biggest fundamental mistake in
D, storage class is improperly used for a bunch of stuff. It's been
killing me slowly for a very long time... and I'm confident after so
many years that you will not succeed.

Supporting cast(@rvalue) doesn't depend on this anyway... you can make that expression work either way.

On Monday, 9 September 2019 at 00:28:17 UTC, Manu wrote:
> Right, you wanna make it a type constructor.
> This should be the case also for ref and scope too... but you will
> *never* get that past Walter.
> This thing you describe is the single biggest fundamental mistake in
> D, storage class is improperly used for a bunch of stuff. It's been
> killing me slowly for a very long time... and I'm confident after so
> many years that you will not succeed.
>
> Supporting cast(@rvalue) doesn't depend on this anyway... you can make that expression work either way.

I'm not bothered too much with ref as long as we have solid pointer types. scope is a compiler hook not that much useful to the programmer.

On Sun, Sep 8, 2019 at 5:45 PM Suleyman via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Monday, 9 September 2019 at 00:28:17 UTC, Manu wrote:
> > Right, you wanna make it a type constructor.
> > This should be the case also for ref and scope too... but you
> > will
> > *never* get that past Walter.
> > This thing you describe is the single biggest fundamental
> > mistake in
> > D, storage class is improperly used for a bunch of stuff. It's
> > been
> > killing me slowly for a very long time... and I'm confident
> > after so
> > many years that you will not succeed.
> >
> > Supporting cast(@rvalue) doesn't depend on this anyway... you can make that expression work either way.
>
> I'm not bothered too much with ref as long as we have solid pointer types. scope is a compiler hook not that much useful to the programmer.

It is though, scope has all the problems ref does, except they're
worse because there's no language to deal with them at all.
For instance, perfect forwarding can't deal with scope. We have talked
about `auto ref` being able to address the perfect forwarding issue
with `@rvalue ref`, but `scope` and `return` has never had any kind of
solution.

On Monday, 9 September 2019 at 01:09:52 UTC, Manu wrote:
> [...]
> For instance, perfect forwarding can't deal with scope. We have talked
> about `auto ref` being able to address the perfect forwarding issue
> with `@rvalue ref`, but `scope` and `return` has never had any kind of
> solution.

Why should there be a solution? Lvaluness is overloadable in D, and with rvalue ref rvaluness also becomes overloadable. scope is not overloadable. Ex:

```
void foo(return scope ref int i) {}
void foo(ref int i) {}

void main()
{
    int i;
    foo(&i); // error: ambiguous call
}
```

On Monday, 9 September 2019 at 01:25:18 UTC, Suleyman wrote:
> [...]
>     foo(&i); // error: ambiguous call

A little mistake there, it should be `foo(i)`.

On Sun, Sep 8, 2019 at 6:30 PM Suleyman via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Monday, 9 September 2019 at 01:25:18 UTC, Suleyman wrote:
> > [...]
> >     foo(&i); // error: ambiguous call
>
> A little mistake there, it should be `foo(i)`.

I mean there's no way for a template parameter to take the scope-ness of its argument... although now I think on it, inference should probably help out there. It's okay because it doesn't change the calling convention like ref does, that's the real problem.

Well, is it particularly hard to try your plan? I guess you might as well do it, and then see what happens if you don't think it's too much work...