Why can't I pass a various numbers of references to a function?

Question

I want to do something like this:

double a, b, c, d, e;
ParseAndWrite("{1, 2, 3}", ref a, ref b, ref c);
ParseAndWrite("{4, 5}", ref d, ref e);

-> a = 1, b = 2, c = 3, d = 4, e = 5

However, I can not write a function like this:

private void ParseAndWrite(string leInput, params ref double[] targets)
{
   (...)
}

This doesn't work, for some reason one can not use ref and params at the same time. Why so?

edit: OK, here's some more information on why I need this: Through an Interface I get a lot of strings containing values, with a syntax like this:

inputConfig : " step, stepHeight, rStep, rStepHeight, (nIterations, split, smooth) "
outputConfig : " dataSelection, (corrected, units, outlierCount, restoreOriginalRange) "

(names in brackets are optional). Those values need to be parsed and stored in all specific variables. That is - they are not arrays at all. They are more like command-line arguments, but around 20 of them. I can of course do all that sequencially, but that produces hundreds of lines of code that contain a redundant pattern and are not well maintainable.

Answer 1

for some reason one can not use ref and params at the same time. Why so?

Consider these three desirable characteristics of cameras:

1. lightweight

2. high-quality lens

3. inexpensive

You get to have at most two of those in any camera. You never get all three. You can get inexpensive heavy big-lens cameras, or expensive lightweight big-lens cameras, or inexpensive lightweight snapshot cameras, but there are no inexpensive, lightweight cameras with big lenses.

Returning now to your question. Consider these three desirable characteristics of a runtime:

1. param arrays of ref-to-variable types are legal

2. type system is safe

3. local variables that have refs to them are still fast to allocate and deallocate

You get to have any two but you can't have all three. Which two would you like?

You can have ref param arrays and a safe type system at the cost of ref'd local variables being allocated on the garbage collected heap. To my knowledge no one does this, but it is certainly possible.

You can have ref param arrays, all local variables allocated on the temporary pool, and a type system that crashes when you use it wrong. This is the "C/C++" approach; it is possible to take a reference and store it in a location that has longer lifetime than the lifetime of the thing being referenced. If you do that, you can expect to have your C++ program crash and die in the most horrible possible ways by making easy mistakes that are hard to detect. Welcome to the pit of despair.

Or we can make ref param arrays illegal, allocate all local variables on the temporary pool, and have a type system that is verifiably memory-safe. That's the choice we made when building C# and the CLR; welcome to the pit of quality.

---

Now, what I said above is actually all a big lie. It's a lie because the runtime, and the C# language, actually do support a feature akin to (but not identical to) parameter arrays of refs. It is a pleasant lie and believe me, you want to live in the world where you believe the lie, so I recommend that you take the blue pill and continue to do so.

If you want to take the red pill and find out how deep the rabbit hole goes, you can use the undocumented __arglist feature of C# to build a C-style variadic method, and then make TypedReference objects that refer to references of arbitrarily fields or locals of struct types, and then pass arbitrarily many of them to the variadic method. Use either the factory methods of TypedReference or the undocumented __makeref feature of C#.

The reason we've kept these features undocumented for the last decade is because they are by design there to be used only for the extremely rare situations where you must write C# code that interoperates cleanly with variadic methods written in other languages.

Correctly using TypedReference objects is not for the faint of heart and again I strongly recommend against doing so. I have never once done so in production code in many years of writing C#. If you want to pass around references to arbitrarily many variables, pass an array. An array is by definition a collection of variables. That is much safer than passing around a bunch of objects that represent managed addresses of instance or local variables.

Answer 2

There's a lot of "why doesn't language X do Y" type questions one could ask. Most often, the answer is because there probably wasn't a great need for that feature.

There's something about a variadic ref parameter set that feels very odd, and I can't imagine it would be useful except in some limited circumstances, and there are typically better abstractions for returning a list of items.

You could pass in a pre-sized double[] for the method to fill, of course, though my preference is to just return an IEnumerable<double>

Answer 3

I don't know if this is the only reason, but here is one potential explanation:

The actual parameter is still ultimately a double[], so in order to do what you want, the compiler would actually need to write that as:

{
    double[] arr = new double[] {a, b, c, d}; // copy in
    YourMethod(arr);
    a = arr[0]; // copy back out
    b = arr[1];
    c = arr[2];
    d = arr[3];
}

However! this changes the semantic. Imagine the calling method was actually:

void SomeCallingMethod(ref double a)
{
    double b = ..., c = ... d = ...;
    YourMethod(ref a, ref b, ref c, ref d);
    /*  which, say, is translated to
    {
        double[] arr = new double[] {a, b, c, d}; // copy in
        YourMethod(arr);
        a = arr[0]; // copy back out
        b = arr[1];
        c = arr[2];
        d = arr[3];
    }  */      
}

The expected behaviour is that we are updating a directly at all times, but in reality we aren't. This could lead to odd and confusing bugs. Indeed, to do it properly the "copy back out" would need to go into a finally, since actually ref values should show changes until the exception, but that still doesn't change the semantic of updating after the method call rather than during.

You also get into a very odd question of: for how long does updating the array update the caller? after all, an array can be stored anywhere, since it isn't on the stack.

---

There is another way of sending that, as an array of references to the values, but that could be really deadly:

• it would make the code essentially unsafe
• if the array was stored anywhere (which arrays can be), the calling method could return and de-scope a local that was being used, meaning that there would be a valid-looking reference that actually points to garbage - major corruption ahoy

---

All in all, no good things come out of doing it, and lots of bad things.

Answer 4

The reason is probably technical. 'params' is just a syntaxic sugar for an array argument. So ParseAndWrite(string leInput, params double[] targets) is compiled as ParseAndWrite(string leInput, params double[] targets).

Then, ParseAndWrite(string leInput, params ref double[] targets) would be compiled as ParseAndWrite(string leInput, ref double[] targets). Basically, it would be the array that is passed as reference, not the actual content of the array. Which obviously wouldn't be the behaviour expected by developers, and would therefore be error-prone.