`in` parameters made useful

[Mathias LANG]

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`.

> How the compiler should know that the argument should be passed 
> by ref?
> I doesn't necessarily know how to load the argument, it may 
> have alignment and synchronization requirements.

As explained in the PR, and in the changelog, the compiler knows 
by inspecting the type. If the type has elaborate copy or 
destruction, IOW, if copying it would have side effects, it will 
always pass it by ref to avoid those side effects.
Otherwise, it asks the backend. The current rule in DMD is for 
types that are over twice the size of a register to be passed by 
ref (or real).

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).


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

> 3. Runtime hooks don't go through semantic checks. Is this a 
> theoretical concern or did you introduce some new behavior that 
> causes problem with this?

Just to be clear: When I said "runtime hook", I meant "the AST 
which the compiler generate to call C functions in druntime". It 
generates the equivalent of a prototype and call that. It's not a 
big deal, and I found a way around.