`in` parameters made useful
geod24 at gmail.com
Thu Aug 20 17:25:43 UTC 2020
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:
> 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
> 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
> 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.
More information about the Digitalmars-d