On Monday, 29 May 2017 at 15:31:26 UTC, WebFreak001 wrote:
> well for the extension functions I wrote that if the ref parameter is the first argument and it's called with ufcs syntax, it could implicitly add the ref probably. I don't think there are any big issues with that, it does look like a member function and the programmer could easily read it as "this modifies it"

Surely better than just requiring ref everywhere. But still, a.swap(b) just feels intuitive. Hard to say what I like here, because the ref parameter is usually the first anyway. Besides swap() you rarely use more than one ref parameter.

On Monday, 29 May 2017 at 08:41:05 UTC, Jonathan M Davis wrote:

> I probably didn't say it very well.
>
> With C++, if you have const T&, it will accept both lvalues and rvalues. A number of folks (particularly those writing games) want an equivalent to that in D where they can then pass both lvalues and rvalues without incurring a copy. Historically, Andrei has been against it because of issues with rvalue references, but based on some of the more recent discussions, it sounds like it _might_ be possible to come up with a solution that he'd be okay with (particularly with some of the improvements that come with DIPs 25 and 1000). Ethan Watson has expressed interest in writing a DIP on the matter, so I expect that we'll see one at some point here.
>
> - Jonathan M Davis

This indeed does sound like a good extension for DIP1000, i.e:

struct Vector3 { float x, y, z; }

void foo(in ref Vector3 v) { /*...*/ }

foo(Vector3(1,2,3));

Invalid now, even with -dip1000, but, since `in` is `const scope` it feels like it should be made allowed: `scope` guarantees the reference won't escape, the argument obviously will live through the call to foo(), so it could be made to "just work", even for mutables, i.e. `scope ref`. Of course, without `scope` it should remain an error.

In regards to move semantics and && also mentioned here, there is only one case where current D looks inferior to C++: D's "double move":

struct X
{
    Y y;
    this(Y y) { move(y, this.y); }
}

auto x = X(Y());
// ctor above benefits from the compiler, so here's
// a more explicit case:
Y y;
X x2 = move(y);

With rvalue references and explicit move semantics of C++, this could be made into one bitblast. With current D, it requires two. However, this does seem like a compiler optimization issue, and is mentioned by Andrei: https://github.com/dlang/phobos/pull/4971#issuecomment-268038627

So all in all, it looks to be possible to achieve the desired results purely by enhancing the language, with no syntax changes and without adding any "rvalue reference" types.

On Monday, May 29, 2017 17:19:27 Stanislav Blinov via Digitalmars-d wrote:
> `in` is `const scope`

Walter recently changed is that in is now just const, because scope was not properly implemented previously, and folks were using in all over the place, so the odds of code breaking when scope was properly implemented were high.

- Jonathan M Davis

On Monday, 29 May 2017 at 19:14:54 UTC, Jonathan M Davis wrote:
> On Monday, May 29, 2017 17:19:27 Stanislav Blinov via Digitalmars-d wrote:
>> `in` is `const scope`
>
> Walter recently changed is that in is now just const, because scope was not properly implemented previously, and folks were using in all over the place, so the odds of code breaking when scope was properly implemented were high.
>
> - Jonathan M Davis

Huh, I missed that... peculiar change. :\ So now it would break for people who did use `in` properly?

In any case, to be clear, I certainly meant `const scope`.

On Monday, May 29, 2017 20:00:12 Stanislav Blinov via Digitalmars-d wrote:
> On Monday, 29 May 2017 at 19:14:54 UTC, Jonathan M Davis wrote:
> > On Monday, May 29, 2017 17:19:27 Stanislav Blinov via
> >
> > Digitalmars-d wrote:
> >> `in` is `const scope`
> >
> > Walter recently changed is that in is now just const, because scope was not properly implemented previously, and folks were using in all over the place, so the odds of code breaking when scope was properly implemented were high.
> >
> > - Jonathan M Davis
>
> Huh, I missed that... peculiar change. :\ So now it would break for people who did use `in` properly?

Since scope was never properly defined for anything other than delegates, it's questionable that _anyone_ who used it used it properly. But regardless, nothing will break because of scope-related stuff unless you use the -dip1000 switch, which would then require scope in a number of places that it wasn't before (including on local variables in a number of cases IIRC), making it so that even if in had stayed const scope, pretty much regardless of how you used it, code would break (which is going to make life fun when when we finally transition from dip 1000 to being optional to being the normal behavior).

- Jonathan M Davis

On Monday, 29 May 2017 at 20:31:18 UTC, Jonathan M Davis wrote:
> On Monday, May 29, 2017 20:00:12 Stanislav Blinov via Digitalmars-d wrote:
>> On Monday, 29 May 2017 at 19:14:54 UTC, Jonathan M Davis wrote:
>> > On Monday, May 29, 2017 17:19:27 Stanislav Blinov via
>> >
>> > Digitalmars-d wrote:
>> >> `in` is `const scope`
>> >
>> > Walter recently changed is that in is now just const, because scope was not properly implemented previously, and folks were using in all over the place, so the odds of code breaking when scope was properly implemented were high.
>> >
>> > - Jonathan M Davis
>>
>> Huh, I missed that... peculiar change. :\ So now it would break for people who did use `in` properly?
>
> Since scope was never properly defined for anything other than delegates, it's questionable that _anyone_ who used it used it properly.

Errm... It was always *defined* (https://dlang.org/spec/function.html#parameters). The fact that it wasn't implemented for anything but delegates is another issue entirely.
Changing spec to please those who didn't care to follow it in the first place just seems weird to me.

> But regardless, nothing will break because of scope-related stuff unless you use the -dip1000 switch, which would then require scope in a number of places that it wasn't before (including on local variables in a number of cases IIRC), making it so that even if in had stayed const scope, pretty much regardless of how you used it, code would break (which is going to make life fun when when we finally transition from dip 1000 to being optional to being the normal behavior).

With that, I see no problem. Yes, enabling dip1000 behavior would cause some breakage, that's the point of having it as a switch in the first place.

On Monday, May 29, 2017 21:13:53 Stanislav Blinov via Digitalmars-d wrote:
> On Monday, 29 May 2017 at 20:31:18 UTC, Jonathan M Davis wrote:
> > On Monday, May 29, 2017 20:00:12 Stanislav Blinov via
> >
> > Digitalmars-d wrote:
> >> On Monday, 29 May 2017 at 19:14:54 UTC, Jonathan M Davis wrote:
> >> > On Monday, May 29, 2017 17:19:27 Stanislav Blinov via
> >> >
> >> > Digitalmars-d wrote:
> >> >> `in` is `const scope`
> >> >
> >> > Walter recently changed is that in is now just const, because scope was not properly implemented previously, and folks were using in all over the place, so the odds of code breaking when scope was properly implemented were high.
> >> >
> >> > - Jonathan M Davis
> >>
> >> Huh, I missed that... peculiar change. :\ So now it would break for people who did use `in` properly?
> >
> > Since scope was never properly defined for anything other than delegates, it's questionable that _anyone_ who used it used it properly.
>
> Errm... It was always *defined*
> (https://dlang.org/spec/function.html#parameters). The fact that
> it wasn't implemented for anything but delegates is another issue
> entirely.
> Changing spec to please those who didn't care to follow it in the
> first place just seems weird to me.

That definition currently there is more precise than the definition on that page has been historically, but even as it stands, it's not particularly precise. Assuming a particular interpretation when the spec is not precise, and the compiler does not implement anything of the sort, is just begging for trouble when the compiler actually does implement something - which is precisely why Walter decided that it was too dangerous to let in imply scope when he actually started implementing scope to do something.

It's quite possible that what some folks assumed scope would do won't run afoul of Walter's changes, but in many cases, it will, and since what he's doing with scope involves stuff like making it so that you have to mark local variables with scope (and not in the way that we've had scoped classes which are supposed to have been deprecated), what he's doing definitely doesn't match what scope was originally, even if it follows the basic idea. But scope has never been well-specified.

- Jonathan M Davis

On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis wrote:

> That definition currently there is more precise than the definition on that page has been historically...

Apparently, it is not. Do you have a reference to Walter's change regarding `in` becoming just `const`? Because a change like that should get reflected in the spec, otherwise we might just continue to ignore said spec and expect our grievances to be "gracefully" resolved later. What I mean is I'd rather see/make the change reflected there...

On Tuesday, 30 May 2017 at 06:13:39 UTC, Stanislav Blinov wrote:
> On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis wrote:
>
>> That definition currently there is more precise than the definition on that page has been historically...
>
> Apparently, it is not. Do you have a reference to Walter's change regarding `in` becoming just `const`? Because a change like that should get reflected in the spec, otherwise we might just continue to ignore said spec and expect our grievances to be "gracefully" resolved later. What I mean is I'd rather see/make the change reflected there...

Unfortunately, `in` was never implemented as `scope const`. I think it was only when Walter started working actively on scope that he found out that it's too late to change this -
https://github.com/dlang/dmd/pull/5898. Here are some more references:
https://github.com/dlang/druntime/pull/1740
https://github.com/dlang/druntime/pull/1749

Going forward, I think it would be best for the language if `in` would work as Q. Schroll described here: http://forum.dlang.org/post/medovwjuykzpstnwbfyy@forum.dlang.org. This can also nicely fix the the problems with rvalues (with auto ref you may end with up to 2^N template instantiations where N is the number of parameters and 2 is because you get one by value and one by ref instance; doesn't play nice with delegates etc). See also https://github.com/dlang/dmd/pull/4717.

On Tuesday, 30 May 2017 at 09:48:09 UTC, Petar Kirov [ZombineDev] wrote:
> On Tuesday, 30 May 2017 at 06:13:39 UTC, Stanislav Blinov wrote:
>> On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis wrote:
>>
>>> That definition currently there is more precise than the definition on that page has been historically...
>>
>> Apparently, it is not. Do you have a reference to Walter's change regarding `in` becoming just `const`? Because a change like that should get reflected in the spec, otherwise we might just continue to ignore said spec and expect our grievances to be "gracefully" resolved later. What I mean is I'd rather see/make the change reflected there...
>
> Unfortunately, `in` was never implemented as `scope const`. I think it was only when Walter started working actively on scope that he found out that it's too late to change this -
> https://github.com/dlang/dmd/pull/5898. Here are some more references:
> https://github.com/dlang/druntime/pull/1740
> https://github.com/dlang/druntime/pull/1749
>
> Going forward, I think it would be best for the language if `in` would work as Q. Schroll described here: http://forum.dlang.org/post/medovwjuykzpstnwbfyy@forum.dlang.org. This can also nicely fix the the problems with rvalues (with auto ref you may end with up to 2^N template instantiations where N is the number of parameters and 2 is because you get one by value and one by ref instance; doesn't play nice with delegates etc). See also https://github.com/dlang/dmd/pull/4717.

Another interesting link: http://dgame.github.io/dneeds/