`in` parameters made useful
spam at here.lot
Fri Aug 21 09:48:16 UTC 2020
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:
>> 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
> 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 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
More information about the Digitalmars-d