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.