`in` on function parameters: const, scope const, ref scope const ?

[Petar]

On Sunday, 5 April 2020 at 02:01:05 UTC, tsbockman wrote:
> On Friday, 3 April 2020 at 06:19:38 UTC, Mathias LANG wrote:
>> I have submitted a PR for it: 
>> https://github.com/dlang/dmd/pull/11000 and would like to know 
>> how other users of `in` expect it to behave, or would want it 
>> to behave.
>
> Given the possibility of aliasing, adding `ref` to parameters 
> that are merely `const`, but not `immutable`, could break 
> existing code in very subtle ways.

Interesting, I wasn't aware of this. Can you elaborate more?

> (I know there has been talk of disallowing aliasing of `ref`
> arguments, but I don't think D's tracking of such things is
> reliable enough to depend on to prevent code breakage yet. Also,
> I'm hoping that proposal isn't actually implemented, anyway,
> because I find intentionally aliasing `ref` parameters useful.)

Can you provide an example?

> However, if I ignore the code breakage issue, then `in` == `ref 
> scope const` is the most aesthetically pleasing option for the 
> symmetry with `out`.

I completely agree.

> I'll also guess that by-value `scope const` is needed a lot less
> often than `ref scope const`, so this is probably the better
> long-term option to reduce the considerable verbosity of the
> language - IF we can avoid breaking too much existing code due 
> the
> altered run-time semantics from adding `ref`.

I think the best option would be what @kinke proposed in that 
pull request:

> I think the optimal solution would be either `const scope` or 
> `const scope ref`, depending on the type and target ABI, for 
> the most efficient way to pass an input parameter. I.e., no ref 
> (extra indirection) for class references and small PODs (incl. 
> delegates and slices for most ABIs), but a ref for non-PODs and 
> large PODs. To be coupled with `-preview=rvaluerefparam` as 
> you've mentioned in the forum thread.

https://github.com/dlang/dmd/pull/11000#issuecomment-608382442