On Monday, 1 April 2019 at 20:17:33 UTC, Timon Gehr wrote:
> On 01.04.19 18:43, bitwise wrote:
>
>> If I had to have my rvalues qualified with const, that would be fine. To be honest, I don't think I've written any C/C++ code that casts const away in years, ...
>
> There is no D const in C++.

I meant that if you had a C function that returned a const object, you could use D's const in the extern(C) D function declaration. If you did that, you could safely cast const away from the returned object knowing that it wasn't some immutable data in D hiding underneath. Aside from this case, I would consider it unnecessary, and in most cases unacceptable, to cast const away.

>> ... > As far as using const, I don't really think it's that bad.
>> 
> Yes, it really is that bad.

Can you provide an example?

   Thanks!

On Tuesday, 2 April 2019 at 17:56:47 UTC, bitwise wrote:
> On Monday, 1 April 2019 at 20:17:33 UTC, Timon Gehr wrote:
>>
>> Yes, it really is that bad.
>
> Can you provide an example?
>

I'm not sure if that sounds like a dumb question, but I don't think I've ever seen a senior member of the D community agree that const should be changed, while responding to arguments made in these forums. Are changes to const actually on the horizon?

On Monday, 1 April 2019 at 16:43:15 UTC, bitwise wrote:
> On Thursday, 28 March 2019 at 16:07:17 UTC, Nicholas Wilson wrote:
>>
>>> It seems like a waste to have a keyword that's just an alias for two others (in = const scope), so why not put 'in' to better use, like to qualify a ref parameter as accepting rvalues, or to outright replace 'ref' for rvalue-ref accepting parameters?
>>
>> Code breakage.
>
> In this case, I think it's worth it.
>
> Dlang's documentation has warned against using 'in' for YEARS:
> https://dlang.org/spec/function.html#param-storage

Try 10 months:
https://github.com/dlang/dlang.org/commit/93411bed24382a08212648c273183d0725cf5dfor
and 15 months for
https://github.com/dlang/dlang.org/commit/71ad1b38d5b5d0a25e383c1dce27e90ed6698f71

> Any code using 'in' right now deserves to break. (but actually, that may not be necessary)

That change is still within our 2 year deprecation period and I think it was not a good move.

> So finally, I would suggest that rvalues only bind to 'in ref'.

This comes down to an opt in vs opt out, 'in ref' (leaving aside the issues with const) mean that bindings and code must be updated to allow use, whereas rvalues not binding to 'out ref' allows immediate use. I'm for opt out.

On Tuesday, 2 April 2019 at 23:40:42 UTC, Nicholas Wilson wrote:
> On Monday, 1 April 2019 at 16:43:15 UTC, bitwise wrote:
>> On Thursday, 28 March 2019 at 16:07:17 UTC, Nicholas Wilson wrote:
>>>
>>>> It seems like a waste to have a keyword that's just an alias for two others (in = const scope), so why not put 'in' to better use, like to qualify a ref parameter as accepting rvalues, or to outright replace 'ref' for rvalue-ref accepting parameters?
>>>
>>> Code breakage.
>>
>> In this case, I think it's worth it.
>>
>> Dlang's documentation has warned against using 'in' for YEARS:
>> https://dlang.org/spec/function.html#param-storage
>
> Try 10 months:
> https://github.com/dlang/dlang.org/commit/93411bed24382a08212648c273183d0725cf5d
> and 15 months for
> https://github.com/dlang/dlang.org/commit/71ad1b38d5b5d0a25e383c1dce27e90ed6698f71

Hey, thanks for looking this up. The situation with 'in' was also explained to me in a forum conversation. Maybe I'm confusing that with seeing the information in the docs. Based on the second link, it couldn't possibly have been be more than 15 months ago that I got this information, but to be honest, I think 15 months still more than enough to support my claim that 'in' has been sitting around collecting dust for a long time and should be put to good use. Even before the change 15 months ago, it was an alias for const, which is arguably useless, and certainly unnecessary.

I think this is all beside the point though, since my argument has evolved to where I believe 'in' can be used as is, as long as the implementation of 'scope' is completed as advertised.

>> Any code using 'in' right now deserves to break. (but actually, that may not be necessary)
>
> That change is still within our 2 year deprecation period and I think it was not a good move.

I don't understand - are you saying it was already deprecated?

I don't see it here:
https://dlang.org/deprecate.html

Even if deprecating it was just a discussion - are there already plans for 'in'?

>> So finally, I would suggest that rvalues only bind to 'in ref'.
>
> This comes down to an opt in vs opt out, 'in ref' (leaving aside the issues with const) mean that bindings and code must be updated to allow use, whereas rvalues not binding to 'out ref' allows immediate use. I'm for opt out.

Was 'out ref' a typo?

In any case, I can think of three ways for a function to accept an rvalue:

1) pass by value
2) use an auto ref template
3) use 'ref' parameters and pass in a temporary local variable created from the rvalue

#1 would require updates either way
#2 already accepts rvalues, so no changes needed
#3 this would still require updates to remove the temporaries and pass the values directly. It would actually be worse because you would have to patch all the invocation sites instead of just the classes/structs that accept the rvalues

Did I miss any?

I suppose that any new code that calls functions with 'ref' parameters could start passing rvalues, but to take advantage of this, the function would have had to be written like #3.

Trying to implement this so things "just work" afterward doesn't seem like a worthwhile constraint to me. I have a 4x4 matrix class, and all things considered, I chose #1.

On Tuesday, 2 April 2019 at 23:40:42 UTC, Nicholas Wilson wrote:
> On Monday, 1 April 2019 at 16:43:15 UTC, bitwise wrote:
>> So finally, I would suggest that rvalues only bind to 'in ref'.
>
> This comes down to an opt in vs opt out, 'in ref' (leaving aside the issues with const) mean that bindings and code must be updated to allow use, whereas rvalues not binding to 'out ref' allows immediate use. I'm for opt out.

BTW `out` can't be used like `ref`, there's no way to pass data in to the function. From the docs:

out	parameter is initialized upon function entry with the default value for its type

On Wednesday, 3 April 2019 at 16:57:10 UTC, bitwise wrote:
> On Tuesday, 2 April 2019 at 23:40:42 UTC, Nicholas Wilson wrote:
>> On Monday, 1 April 2019 at 16:43:15 UTC, bitwise wrote:
>>> On Thursday, 28 March 2019 at 16:07:17 UTC, Nicholas Wilson wrote:
>>> Any code using 'in' right now deserves to break. (but actually, that may not be necessary)
>>
>> That change is still within our 2 year deprecation period and I think it was not a good move.
>
> I don't understand - are you saying it was already deprecated?

No, I'm saying I don't think it was a good move to change it for const scope to const.
I certainly don't remember any community discussion about it at  the time.

> Even if deprecating it was just a discussion - are there already plans for 'in'?

In theory it is becoming synonymous with 'const'.

>>> So finally, I would suggest that rvalues only bind to 'in ref'.
>>
>> This comes down to an opt in vs opt out, 'in ref' (leaving aside the issues with const) mean that bindings and code must be updated to allow use, whereas rvalues not binding to 'out ref' allows immediate use. I'm for opt out.
>
> Was 'out ref' a typo?

No, sorry I forgot to define it. Out ref would mean 'one point of this function is to mutate that argument as a side effect so it can't be an rvalue.'

On Thursday, 4 April 2019 at 00:16:11 UTC, Nicholas Wilson wrote:
> On Wednesday, 3 April 2019 at 16:57:10 UTC, bitwise wrote:
>> On Tuesday, 2 April 2019 at 23:40:42 UTC, Nicholas Wilson wrote:
>>> On Monday, 1 April 2019 at 16:43:15 UTC, bitwise wrote:
>>>> On Thursday, 28 March 2019 at 16:07:17 UTC, Nicholas Wilson wrote:
>>>> Any code using 'in' right now deserves to break. (but actually, that may not be necessary)
>>>
>>> That change is still within our 2 year deprecation period and I think it was not a good move.
>>
>> I don't understand - are you saying it was already deprecated?
>
> No, I'm saying I don't think it was a good move to change it for const scope to const.
> I certainly don't remember any community discussion about it at
>  the time.

+1. I *want* `in` to be `scope const`. Any code that breaks as a result of DIP1000 that uses `in` deserves to break anyway.

On Thursday, 4 April 2019 at 13:43:32 UTC, Atila Neves wrote:
> +1. I *want* `in` to be `scope const`. Any code that breaks as a result of DIP1000 that uses `in` deserves to break anyway.

Do you have any preference on whether or not 'in' is required for an rvalue to bind to ref?

On Thursday, 4 April 2019 at 19:29:54 UTC, bitwise wrote:
> On Thursday, 4 April 2019 at 13:43:32 UTC, Atila Neves wrote:
>> +1. I *want* `in` to be `scope const`. Any code that breaks as a result of DIP1000 that uses `in` deserves to break anyway.
>
> Do you have any preference on whether or not 'in' is required for an rvalue to bind to ref?

No. Especially not before seeing the new DIP for that.

On Friday, 5 April 2019 at 12:19:34 UTC, Atila Neves wrote:
> On Thursday, 4 April 2019 at 19:29:54 UTC, bitwise wrote:
>> On Thursday, 4 April 2019 at 13:43:32 UTC, Atila Neves wrote:
>>> +1. I *want* `in` to be `scope const`. Any code that breaks as a result of DIP1000 that uses `in` deserves to break anyway.
>>
>> Do you have any preference on whether or not 'in' is required for an rvalue to bind to ref?
>
> No. Especially not before seeing the new DIP for that.

Could you please explain?

At this point, I was suggesting that 'in' be used without changes, so no DIP should be required for that.

As far as the new rvalue DIP, I would only add `in` as an additional requirement for rvalues binding to `ref`. The only issue I can see with this is `in` indirectly adding `scope` to a `ref` parameter, which after DIP25, doesn't really make sense.

DMD v2.085.0 does allow adding `scope` to a `ref` param with -dip25, which seems odd. Do the duplicate storage classes collapse by design (like C++'s reference collapsing), or will 'scope ref' eventually fail to compile or change meaning?