« Anders On C# 6.0 at BUILD 2013 | Main | Immutable & Isolated Types Likely in Future C# »

November 27, 2013

“In” Parameters Proposal for C# 6.0

I propose a new feature that will make manipulation of value types more efficient, produce more readable code, and encourage greater use of the functional programming style. I disclaim any ownership to this idea.

Currently, there are two C# keywords that allow parameters to be passed by reference, “ref” and “out.” I will confine the discussion to “ref” parameters.

The “ref” keyword has several disadvantages:

  1. For large value type structures, copying by value is wasteful. It may be more more efficient to passed a structure by reference. One such example of a real world data structure is the Matrix3D data type in WPF.
  2. The variable passed by reference may be modified by the function.
  3. The ref keyword must precede all arguments passed to a ref parameter resulting in ugly syntax.
  4. Only L-values may be passed by reference. L-value are variables and other expressions  that may appear in left-hand side of an assignment. These include including locals, field accesses, pointer dereferences, and array element accesses. L-values do not include property accesses, which do not have an identifiable machine address, nor do they include read-only fields, which are restricted by the CLR.
  5. Ref parameters can not be the target of an extension method. Extension methods calls are expensive for value types, because the “this” parameter is copied by value. This also means that value types can’t have mutable extension methods. This is in direct contrast to instance methods, which pass the value type “this” parameter by reference.
  6. Ref parameters can not be used in operator overloading functions.

The implementation of an “in” parameter would be very similar to a “ref” parameter.

  1. The signature of a function with an “in” parameter would be identical to that of an “ref” parameter in MSIL, just as “out” parameters are today. An InAttribute would be applied to an “in” parameter in a manner similar to how the OutAttribute is currently applied to “out” parameters.
  2. The “in” keyword would not be required at the calling site as “ref” and “out” are currently required today.
  3. An L-value passed to an “in” parameter would be prevented by the compiler from being modified by the function called.
  4. R-values could be passed by reference to an “in” parameter. This is one of the benefits of using const references in C#. For instance, one could write Determinant(matrix1 * matrix2 + matrix3)) and the three temporary values would be passed by reference in addition to the three variables.

Other languages such as Ada have an “in” parameter, though I do not know if they behave similarly.

UPDATE: The keyword “in” is very must like “const” references in C++, but it is actually much easier to introduce constness behavior in .NET without the cascading mess of introducing const to other parts of the codebase and libraries.

An “in” variable is not modified if it is passed to another method through an “in” parameter or a regular copy-by-value parameter. It may be modified by an instance method or passage through “ref” and “out” parameter in another method. It’s also modified if any of fields are directly modified in method, possibly through inlining of short methods. After just-in-time compilation, short methods and property accesses are inlined. Simple property getter will become direct field accesses and it would be possible to ascertain whether modifications are made to the data structure.

If there are still potential modifications through instance method calls, the “in” parameter can be copied to a local variable by the compiler before being used. The compiler can prevent modifications to public fields or, alternatively, prevent modifications from propagating to the caller by using a local copy.

An “in” parameter isn’t strictly necessary as the compiler and runtime can already implement copy-by-value this way for large structures. However, the difference in behavior is visible in multithreaded code and through closures containing writable captured variables, if the value referenced is not stored on the stack.

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8345242f069e2019b01b80b50970c

Listed below are links to weblogs that reference “In” Parameters Proposal for C# 6.0:

Comments

I don't like it. I was writing a long comment based on my experiences with Delphi, a language without a C++-style const, but with 'const' parameters that were introduced specifically to solve this problem, but the comment got too long. I'll try to summarize.

Basically: nobody will know whether to use it or not, and it will end up polluting APIs, split between those who use it because they think it communicates semantic intent, those who think it's faster, and those who use it like you probably think it should be used - for performance critical ops on big value types. It only applies to value types. The guarantees about fewer copies aren't very strong when so many operations may force a copy. It will introduce a notion of constness in C# expressions that the language has never had before (this will primarily be reflected in error messages).

Immutable and isolated is coming to C#. At least, the in parameter doesn't propagate like C++ const or produce as many errors. It's primary benefit is with large structs.

The comments to this entry are closed.