`in` parameters made useful

[Mathias LANG]

On Friday, 21 August 2020 at 09:48:16 UTC, Kagamin wrote:
>
> 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.

The first example is pretty good: We probably need to specify the 
interaction with `shared`. AFAICS it boils down to "when do we 
want to read a `shared` value ?".
If we pass by value, it means the input parameter will only have 
a single value, while if we pass by ref, a function can "listen" 
to changes.
I don't really have an answer for this at the moment, I would 
need to try out some options before I make up my mind.

The second example is pretty simple: the backend will decide 
whether to pass it by ref or not. Since it's a small type, it 
might make more sense to pass it in registers. Whether or not 
it's ref does not matter to the programmer, because the 
programmer cannot change the input anyway, only read it.

>>> 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?

I don't see how ?