Question: Why C# doesn't allow passing parameter as final?

[AhmedRagheb]

In Java, you can mark variable as final

public void GetById(final int id)
{
    // Get by id and don't change id 
}

Why this is not allowed in C#.
There are many questions like this in Stackoverflow but I prefer to ask here to get the right reason behind that, not just theoretical answers.

[DavidArno]

That's coming in C# 7.2, using in.

See SharpLab example for the feature in action. (Or download a preview of VS2017.5 to try it out).

[mikedn]

That's coming in C# 7.2, using in.

Nope. in int is really ref readonly int, that's not the same as readonly int.

[DavidArno]

@mikedn,

How is it different in practice?

[mikedn]

How is it different in practice?

Hmm, that should be obvious. ref readonly int passes an int by reference and prevents you from modifying it. In 99.99% of the cases doing that is completely pointless. And slower too. And makes the method signature incompatible with one that passed the int by value.

readonly int simply prevents the code inside the method to modify the parameter. It doesn't change the signature, it doesn't affect performance etc.

I would hope that people don't start using in int as a surrogate for readonly int, that would be pretty obnoxious.

[Joe4evr]

Also, take into account that if you're passing a struct type (like int) not by ref, then changes to that parameter aren't observable at the caller because it's a value copy.

[DavidArno]

I would hope that people don't start using in int as a surrogate for readonly int, that would be pretty obnoxious.

Ah, that's unfortunate as that is exactly what I plan on doing. I don't really care what the compiler does under the hood. in let's me mark a parameter as read-only, so I fully intend using it that way. 😇

[mikedn]

Ah, that's unfortunate as that is exactly what I plan on doing. I don't really care what the compiler does under the hood

I hope I'll never have to read/update code written by you 😁

[DavidArno]

@mikedn,

Just to clarify, your position is:

1. in is possibly slower than a dedicated readonly modifier,
2. There is no readonly modifier planned for 7.2,
3. in still shouldn't be used as "read-only" because it might be slower and/or because it's somehow "obnoxious" to do so.

Questions:

1. Is the above an accurate summary of your position?
2. Do you have any evidence that it is slower? Have you measured it?
3. Surely worrying about that potential slowness is simple micro-optimisation?
4. In what way, other than possibly making the code slower, is it "obnoxious" to use a feature that (almost) exists, as opposed to waiting for a feature that might never happen?

[VisualMelon]

@DavidArno
I think mikedn's position also includes the considerably more important stance that because in is actually a reference it can change, and that means the caller can break their code in exciting ways they don't realise; I'll add that it's even worse than that, because there is nothing at the call-site telling you that you are passing an lvalue by reference: this is an obnoxious concept and I still can't believe they are going with it!!!.

I can't think of many reasons not to add a readonly modifier (which has no change of semantics at the call site, unlike in) to improve method implementations without fear of the in keyword and its numerous subtleties. People will of course tell me that hardly anyone will use it because in is shorter to type (you'll be unsurprised to hear that I don't think much of arguments that appeal to the length of tokens). Another reason not to add readonly, of course, is that then ref readonly would look like it should exist, and that could create confusion (I'd rather it did exist, so that I don't have to go anywhere near in ever).

Regarding Question 3, waiting would be a problem because in will be in the wild and ruining lives (this might be hyperbole), but people will learn to use it and then won't use readonly if it were to be added (more over, it might never be added because people will - as you have - suggest using in instead). Personally, I would be very glad to see readonly added (with or without a call-site signature, no change in semantics means the call-site doesn't care, so it could be completely backward compatible; readonly ref is a different concern); I think the in keyword is a disaster.

I'm sorry this turned into another rant...

[Joe4evr]

Another reason not to add readonly, of course, is that then ref readonly would look like it should exist

But ref readonly does exist - in is just an alias for both modifiers.

[VisualMelon]

@Joe4evr indeed, I meant only to refer to the syntax, to suggest that people might ask "why can't I type ref readonly" (which would be a reasonable question) to which the answer would be "it's called in". It's just another little surprise that I think would be worth avoiding, though it's rather a petty concern.

[VisualMelon]

Some points about performance (which I agree is pretty irrelevant; but, as I understand it in is being added primarily to support code that is required to be fast: it seems kind of reasonable to hold it to its own account):

An in parameter may be changed by a different thread: this may well have performance implications when writing threaded code, as memory barriers could prevent optimisations that would otherwise be made when assuming single threaded execution. I haven't spent much time looking at generated assembly recently, but I presume that a ref lookup also requires an additional indirection, so repeated access (again, in a multi-threaded context) could be slower, though in practise this is what CPUs are good at so probably not.

Really, any external call could modify an in parameters target. I don't know for certain how refs are presently treated in this instance, but presumably in will work the same way (either by producing undefined behaviour at the whim of the JIT, or aggressively looking up 'invalidated' refs (I would assume this is the case; note that no 'real' memory barrier is required)).

I vaguely recall reading that when passing an rvalue to in, it (semantically) makes a copy at the call-site and passes a reference (rather than JITing one of the 2^N possible versions of the method, or something like that), so these ref concerns will always be present, and indeed there will be an added overhead at the call-site for rvalues (equal, I should think, to the cost of passing a ByVal param), though I can imagine that this will usually be optimised away.

Again, I really only care about the semantic concerns which throw up these same performance concerns, and I doubt that legitimate use of in will regularly coincide with a need for blazing performance and intricate multi-threading/dodgy external calls, so I agree with David that performance alone wouldn't warrant another keyword (it's the semantics that warrant a different keyword!)

[mikedn]

In what way, other than possibly making the code slower, is it "obnoxious" to use a feature that (almost) exists, as opposed to waiting for a feature that might never happen?

Well, I don't know, the simple fact that in is part of the method signature should be enough to rise eyebrows. Any gratuitous use of a language feature in ways it wasn't designed for is obnoxious. Even more so if it turns out that the language feature is not well understood.

[DavidArno]

@mikedn,

Well, I don't know, the simple fact that in is part of the method signature should be enough to rise eyebrows.

readonly would be part of the method signature too.

[DavidArno]

@VisualMelon,

I think mikedn's position also includes the considerably more important stance that because in is actually a reference it can change, and that means the caller can break their code in exciting ways they don't realise;

Doesn't the fact that in parameters can be changed less than existing parameters negate this concern?

• a non-readonly struct will have a copy made before passing by reference so internal state changes won't affect the callee,
• a read-only struct can't have their internal state changed,
• reference types are already passed by reference, so can already have their internal state changed.
• by using in, you prevent re-assignment, ie less change than before.

[benaadams]

why then people say that in performance is ever worse, than simple parameter one?

For small value types its bad; unless you want the live link behviour (which is more-likely an unexpected side-effect)

in int passes a reference (8-bytes on x64) in CPU register; which then needs to be deferenced to get the value from stack memory every time it is used (as its a live link - not copy).

int passes a its actual value (4 bytes on x64) in a CPU register which can then be used directly (literally a copy in register, fastest memory on CPU).

For large value types its good

in Matrix4x4 passes a reference (8-bytes on x64) in CPU register; which then needs to be deferenced to get the value from stack memory every time it is used (as its a live link - not copy).

Matrix4x4 copies the struct to stack first; as its too large for register, then passes a reference (8-bytes on x64) in CPU register; which then needs to be deferenced to get the value from stack memory every time it is used (as its a live link - not copy, though would never change).

tl;dr in is a speed up for large value-types and a slow down for small value types

For large value types it skips this bit copies the struct to stack first; for small value types it adds this bit deferenced to get the value from stack memory every time it is used

[Pzixel]

@benaadams anyhow, why not then use it automatically when you can profit from it? It seems that the rule is simply use ref if type size is bigger than X otherwise don't.

[benaadams]

why not then use it automatically when you can profit from it?

Because they are different things

public class Program
{
    private static int _value;

    private static void AddToValue()
    {
        _value += 5;
    }

    private static void PrintValueByParam(int value)
    {
        Console.WriteLine(nameof(PrintValueByParam));
        Console.WriteLine(value);
        AddToValue();
        Console.WriteLine(value);
    }

    private static void PrintValueByIn(in int value)
    {
        Console.WriteLine(nameof(PrintValueByIn));
        Console.WriteLine(value);
        AddToValue();
        Console.WriteLine(value);
    }

    public static void Main(string[] args)
    {
        _value = 0;
        PrintValueByParam(_value);
        _value = 0;
        PrintValueByIn(in _value);
    }
}

Outputs

PrintValueByParam
0
0
PrintValueByIn
0
5

[Pzixel]

@benaadams so this is a low-level unsafe feature for bit hacking. Am I right?

[HaloFour]

@Pzixel

so this is a low-level unsafe feature for bit hacking. Am I right?

It's a "lower-level" safe feature for fast math. Operations like this are common in libraries like XNA and they are currently burdensome to use in C# since to be performant the parameters are declared ref which makes them a lot harder to consume.

I would agree that it is somewhat niche compared to the C# market as a whole and does require a good degree of understanding on the part of the library authors in order to use correctly.

[benaadams]

Not really its to both imply intent and have compiler enforcement of it e.g. previously you'd be using ref here due to the performance difference:

Method	Mean	Error	StdDev
Matrix4x4ByValue	212.2870 ns	1.2065 ns	1.1285 ns
Matrix4x4ByRef	159.5631 ns	0.5604 ns	0.5242 ns

private static Vector4 DoMaths(ref Matrix4x4 matrix, Vector4 value)

However ref suggests the the called function will be changing the value; which is wrong on many levels; rather than just using the value.

So its so you can do:

private static Vector4 DoMaths(readonly ref Matrix4x4 matrix, Vector4 value)

Or the shorter in

private static Vector4 DoMaths(in Matrix4x4 matrix, Vector4 value)

Which implies the intent better and also enforces only read in the method.

Probably what many people are after is: "readonly for locals and parameters" #188 so you could do:

void PrintValue(readonly int value)

i.e. "readonly by value" rather than "readonly by reference"

[HaloFour]

@benaadams

Which implies the intent better and also enforces only read in the method.

How exactly does in imply the intent better? I think that if anything this conversation demonstrates how ambiguous that term is. I've found very little info in design meetings as to why in seems to be favored over the much more explicit readonly ref. Sure, that's a lot more verbose, but if it only needs to be applied at the parameter declaration then that only impacts library authors which should represent the relative minority of code.

[benaadams]

@HaloFour

Which implies the intent better and also enforces only read in the method.

How exactly does in imply the intent better?

readonly ref vs ref

I assume in is for the triple of ref passing; all of which will change the signature and calling convention for the caller:

• in - read only by called function
• ref - read/write by called function
• out - write only by called function

readonly alone on the other hand is irrelevant to the caller and only important inside the called function

[benaadams]

The question I suppose is would in be as confusing if readonly existed? 👍 👎

[mikedn]

The question I suppose is would in be as confusing if readonly existed?

IMO it would be even more confusing.

Developer X:

in?! readonly?! They look the same to me. I'll just use in cause it's shorter.

[HaloFour]

@benaadams

It's a quartet. We already have "no modifier" which already means "read only by called function" by virtue of being by value. The new modifier means "read only reference by called function", which in doesn't remotely convey. I understand that it may serve as a counterpoint to out which doesn't explicitly call out the fact that it is a reference, but that nature is implied by the fact that it couldn't actually write a value to the parameter affecting the caller in any other way.

readonly alone on the other hand is irrelevant to the caller and only important inside the called function

I disagree. readonly is critically important here as it is what allows the caller to significantly relax rules about what it may pass to that parameter, including readonly fields which would normally be verboten. Again, I don't think that in conveys this.

That's really my only concern here. Combined with the fact that this feature is relatively niche and requires a decent working knowledge of structs I don't think that the feature should be made super-easy to (mis)use. I'm fine with the omission of the modifier from the call-site though.

[VisualMelon]

@HaloFour I read @benaadams 's comment regarding readonly as referring to the proposed non-ref readonly ("readonly alone on the other hand..."), where the semantics are indeed irrelevant to the call-site. I think we all agree now that whatever type of ref it is, it needs to be declared at the call-site (ref readonly or otherwise).

Addendum: I agree that having readonly explicit for readonly ref (as oppose to just the wishy-washy in) would be nice at the call-site

[HaloFour]

@VisualMelon

I'm not sure how much sense that makes given that you can pass expressions to the readonly ref parameter, and that it applies to scenarios where there's no where to put a modifier at all, such as the target of an extension method or an operand with an overloaded operator.

[benaadams]

@HaloFour

readonly alone on the other hand is irrelevant to the caller and only important inside the called function

I disagree. readonly is critically important here...

I mean to the caller, these are identical:

void PrintValue(int value)
void PrintValue(readonly int value)

So the readonly is irrelevant to the caller.

[VisualMelon]

@HaloFour
I've said many times (and I think I will have write all my complains about in into a single issue tonight) that I really couldn't care less about difficulties with extension methods and operators: there is no excuse for leaving the most common type of method call ambiguous. I'd sooner simply not allow operators and extension methods (i.e. anywhere it is ambiguous for lack of syntax) to have in semantics: if you want performance, use a normal method call (I would support this). in is all about performance for the few that need it, not about confusing everyone (including, even especially the few) by allowing silent and painful to debug API changes.

You are right that it would look odd passing an expression to a readonly ref... so do something special with rvalues (not that I would necessarily condone this, but if the call-site semantics are the same as ByVal then it would be fine to omit in/readonly ref when passing an expression), implicitly passing a reference to an lvalue is a dreadful idea. Again, this is a feature targeted at those with serious performance concerns, if it's ugly in cases where it doesn't help (ignoring opportunities for dodgy compiler optimisations) then who cares?