Would like to see ref and out required for function calls

Chris Nicholson-Sauls ibisbasenji at gmail.com
Sat Sep 8 06:05:30 PDT 2012


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.


More information about the Digitalmars-d mailing list