Given:
void func (ref int[], int)
If ref/out were required at the call site, this destroys UFCS.
int[] array;
array.func(0); // error, ref not specified by caller
Or would one expect something like:
(ref array).func(0);
...put simply, I hope not.
This suggestion has come up a couple times before, and each time
failed to gain traction. I wouldn't mind it as an option --
possibly even as a recommendation in most library code -- but as
a requirement it honestly just gives me a headache. Generally
speaking, if a parameter being ref/out is surprising, there is
something wrong with the design. (There are times it is
non-obvious in otherwise good code, this seems uncommon.)
For example, calling one of the *InPlace functions from Phobos, I
immediately expect 'ref' -- otherwise, how to modify "in place"
in a reliable (ie, non-allocating) manner? Likewise, 'out' --
used pretty rarely in the first place -- sits in the same place
pointers typically do, as auxiliary returns. The category of
functions/methods which use them is pretty self consistent.
(What few corner cases remain would be better served by cleaning
up tuples to make them more sane as return values.)
Given:
bool checkedEmitJ (Op, Params, ref const(Scope), Address, out
Address)
I really don't want to have to call it as:
auto handled = checkedEmitJ(Op.CJmp, parms, ref _scope, suggest,
out lval);
When the 'ref' and 'out' parameters listed are specified by the
design and consistent across all the "-emit-" functions.
