C#•12mo ago

Declaring methods with `in` parameters

If a I'm writing a synchronous method, should I always declare read-only value types with the

in

in

keyword.

void Foo(in int i)
{
    
}

void Foo(in int i)
{
    
}

void Foo(in int i)
{
    
}

void Foo(in int i)
{
    
}

Angius•1/8/25, 7:49 PM

in

in

is basically readonly refreadonly ref

Angius•1/8/25, 7:49 PM

Only matters when passing some super large structs, to avoid copying

Angius•1/8/25, 7:50 PM

fwiw, I've seen

in

in

used in the wild maybe, like, twice

nathanAjacobsOP•1/8/25, 7:51 PM

But are there downsides to declaring it like this or is just overkill?

From what I understand the caller doesn't have to specify the

in

in

keyword when calling the method, but still benefit from it.

Angius•1/8/25, 7:52 PM

Overkill

Angius•1/8/25, 7:52 PM

And only really works with value types

Angius•1/8/25, 7:52 PM

For reference types, you're already passing a reference

nathanAjacobsOP•1/8/25, 7:54 PM

Yeah I know it is just for value types, but was just curious what the general consensus was. Like at what point do I need to consider using it

333fred•1/8/25, 8:19 PM

There are downsides, yes. There's more overhead to ref parameters

333fred•1/8/25, 8:20 PM

Unless you have a struct over 16 bytes, you probably shouldn't use it

nathanAjacobsOP•1/8/25, 8:23 PM

Okay now I'm curious, what is the overhead?

333fred•1/8/25, 8:26 PM

Refs are tracked by the gc

nathanAjacobsOP•1/8/25, 8:43 PM

even for structs that contain no reference types?

333fred•1/8/25, 8:43 PM

Yes. The location of the struct could change

333fred•1/8/25, 8:44 PM

For example, if you passed a ref to a field of a reference type

333fred•1/8/25, 8:45 PM

Even if there's no chance the location can change, knowing that is a tiny bit of overhead