`in` parameters made useful

[Kagamin]

On Thursday, 20 August 2020 at 17:25:43 UTC, Mathias LANG wrote:
> On Thursday, 20 August 2020 at 15:59:24 UTC, Kagamin wrote:
>> On Friday, 31 July 2020 at 21:49:25 UTC, Mathias LANG wrote:
>>> https://github.com/dlang/dmd/pull/11000
>>
>> 1. Deprecation of `in ref` makes no sense. Why? I assume it's 
>> due to a bug in the proposed change.
>
> I'm not in the business of deprecating something to accommodate 
> for a broken implementation, no. The implementation originally 
> allowed `in ref`, but after some tinkering and looking at 
> people's usages, my opinion is that it would be better to just 
> allow `in`.

It needlessly degrades language and breaks code and shouldn't be 
done. Didn't you write this pull because you believe `in ref` is 
useful?

> I can't think of a situation where the compiler doesn't know 
> how to load the argument. If you're talking about opaque types, 
> those are rejected.
>
>> And more importantly how the programmer can know whether the 
>> argument is passed by ref, now that it varies by platform?
>
> I don't understand why it would be "more important". The point 
> of `in` parameter is that it does the right thing for 
> parameters which are read-only and won't escape the scope of 
> the function. It doesn't matter to the user whether your 
> parameter is `ref` or not if it is `scope const`, because you 
> can't modify it anyway. It only matters if passing it by value 
> would be expensive (e.g. large static array) or have side 
> effects (e.g. a destructor).

I mean things like
int atomicLoad(in ref shared int n);
int loadAligned(in ref byte[4] n);
When the argument should be passed by ref by programmer's intent 
and should be communicated to the compiler, because the compiler 
isn't that smart.

>> 2. Dependence on calling convention. AIU ref semantics depends 
>> on parameter position?
>
> Yes. Originally didn't, but that was the main feedback I got, 
> that it should be done at the function level instead of the 
> parameter (type) level.

Doesn't this defeat your optimization when passing by value is 
expensive?