Mixing
Why would one ever use the “in†parameter modifier in C#?
Clash Royale CLAN TAG#URR8PPP
up vote
9
down vote
favorite
So, I (think I) understand what the in parameter modifier does. But what it does appears to be quite redundant.
Usually, I'd think that the only reason to use a ref would be to modify the calling variable, which is explicitly forbidden by in. So passing by in reference seems logically equivalent to passing by value.
Is there some sort of performance advantage? It was my belief that on the back-end side of things, a ref parameter must at least copy the physical address of the variable, which should be the same size as any typical object reference.
So, then is the advantage just in larger structs, or is there some behind-the-scenes compiler optimization that makes it attractive elsewhere? If the latter, why shouldn't I make every parameter an in?
c# c#-7.2
edited 24 mins ago
Magnetron
2,271719
asked 55 mins ago
Travis Reed
463
New contributor
Travis Reed is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
9
down vote
favorite
So, I (think I) understand what the in parameter modifier does. But what it does appears to be quite redundant.
Usually, I'd think that the only reason to use a ref would be to modify the calling variable, which is explicitly forbidden by in. So passing by in reference seems logically equivalent to passing by value.
Is there some sort of performance advantage? It was my belief that on the back-end side of things, a ref parameter must at least copy the physical address of the variable, which should be the same size as any typical object reference.
So, then is the advantage just in larger structs, or is there some behind-the-scenes compiler optimization that makes it attractive elsewhere? If the latter, why shouldn't I make every parameter an in?
c# c#-7.2
edited 24 mins ago
Magnetron
2,271719
asked 55 mins ago
Travis Reed
463
New contributor
Travis Reed is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Yes, there is a performance advantage.refis used to pass structs by reference instead of copying them.inmeans the struct shouldn't be modified.
– Panagiotis Kanavos
52 mins ago
@dbc no, this has nothing to do with interop
– Panagiotis Kanavos
50 mins ago
2
Performance for value types.The New “in†Keyword For C# 7.2
– Silvermind
50 mins ago
Detailed discussion here. Note the last warning:It means that you should never pass a non-readonly struct as in parameter.
– Panagiotis Kanavos
46 mins ago
add a comment |Â
up vote
9
down vote
favorite
up vote
9
down vote
favorite
So, I (think I) understand what the in parameter modifier does. But what it does appears to be quite redundant.
Usually, I'd think that the only reason to use a ref would be to modify the calling variable, which is explicitly forbidden by in. So passing by in reference seems logically equivalent to passing by value.
Is there some sort of performance advantage? It was my belief that on the back-end side of things, a ref parameter must at least copy the physical address of the variable, which should be the same size as any typical object reference.
So, then is the advantage just in larger structs, or is there some behind-the-scenes compiler optimization that makes it attractive elsewhere? If the latter, why shouldn't I make every parameter an in?
c# c#-7.2
edited 24 mins ago
Magnetron
2,271719
asked 55 mins ago
Travis Reed
463
New contributor
Travis Reed is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
So, I (think I) understand what the in parameter modifier does. But what it does appears to be quite redundant.
Usually, I'd think that the only reason to use a ref would be to modify the calling variable, which is explicitly forbidden by in. So passing by in reference seems logically equivalent to passing by value.
Is there some sort of performance advantage? It was my belief that on the back-end side of things, a ref parameter must at least copy the physical address of the variable, which should be the same size as any typical object reference.
So, then is the advantage just in larger structs, or is there some behind-the-scenes compiler optimization that makes it attractive elsewhere? If the latter, why shouldn't I make every parameter an in?
c# c#-7.2
c# c#-7.2
edited 24 mins ago
Magnetron
2,271719
asked 55 mins ago
Travis Reed
463
New contributor
Travis Reed is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 24 mins ago
Magnetron
2,271719
asked 55 mins ago
Travis Reed
463
New contributor
Travis Reed is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 24 mins ago
Magnetron
2,271719
edited 24 mins ago
Magnetron
2,271719
edited 24 mins ago
Magnetron
2,271719
2,271719
asked 55 mins ago
Travis Reed
463
New contributor
Travis Reed is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 55 mins ago
Travis Reed
463
asked 55 mins ago
Travis Reed
463
463
New contributor
Travis Reed is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Travis Reed is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Travis Reed is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Yes, there is a performance advantage.refis used to pass structs by reference instead of copying them.inmeans the struct shouldn't be modified.
– Panagiotis Kanavos
52 mins ago
@dbc no, this has nothing to do with interop
– Panagiotis Kanavos
50 mins ago
2
Performance for value types.The New “in†Keyword For C# 7.2
– Silvermind
50 mins ago
Detailed discussion here. Note the last warning:It means that you should never pass a non-readonly struct as in parameter.
– Panagiotis Kanavos
46 mins ago
add a comment |Â
Yes, there is a performance advantage.refis used to pass structs by reference instead of copying them.inmeans the struct shouldn't be modified.
– Panagiotis Kanavos
52 mins ago
@dbc no, this has nothing to do with interop
– Panagiotis Kanavos
50 mins ago
2
Performance for value types.The New “in†Keyword For C# 7.2
– Silvermind
50 mins ago
Detailed discussion here. Note the last warning:It means that you should never pass a non-readonly struct as in parameter.
– Panagiotis Kanavos
46 mins ago
Yes, there is a performance advantage.
ref is used to pass structs by reference instead of copying them. in means the struct shouldn't be modified.– Panagiotis Kanavos
52 mins ago
Yes, there is a performance advantage.
ref is used to pass structs by reference instead of copying them. in means the struct shouldn't be modified.– Panagiotis Kanavos
52 mins ago
@dbc no, this has nothing to do with interop
– Panagiotis Kanavos
50 mins ago
@dbc no, this has nothing to do with interop
– Panagiotis Kanavos
50 mins ago
2
2
Performance for value types.The New “in†Keyword For C# 7.2
– Silvermind
50 mins ago
Performance for value types.The New “in†Keyword For C# 7.2
– Silvermind
50 mins ago
Detailed discussion here. Note the last warning:
It means that you should never pass a non-readonly struct as in parameter. – Panagiotis Kanavos
46 mins ago
Detailed discussion here. Note the last warning:
It means that you should never pass a non-readonly struct as in parameter. – Panagiotis Kanavos
46 mins ago
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
6
down vote
in was recently introduced to the C# language.
in is actually a ref readonly. Generally speaking, there is only one use case where in can be helpful: high performance apps dealing with lots of large readonly structs.
Assuming you have:
readonly struct VeryLarge
public readonly long Value1;
public readonly long Value2;
// etc
and
void Process(in VeryLarge value)
In that case, the VeryLarge struct will be passed by-reference without creating of defensive copies when using this struct in the method, and the struct immutability is ensured by the compiler.
Note that passing a not-readonly struct with an in modifier will cause the compiler to create a defensive copy when using that struct in the method, which will negatively affect performance!
There is a really good MSDN blog entry which I recommend to carefully read.
If you would like to get some more historical background of in-introducing, you could read this discussion in the C# language's GitHub repository.
In general, most developers agree that introducing of in could be seen as a mistake. It's a rather exotic language feature and can only be useful in high-perf edge cases.
answered 49 mins ago
dymanoid
6,45421844
add a comment |Â
up vote
2
down vote
There is. When passing a struct, the in keyword allows an optimization where the compiler only needs to pass a pointer, without the risk of the method changing the content. The last is critical — it avoids a copy operation. On large structs this can make a world of difference.
edited 48 mins ago
Joel Coehoorn
300k94487714
answered 51 mins ago
TomTom
48k363118
1
This is just repeating what the question already says, and doesn't answer the actual question it asks.
– Servy
45 mins ago
Only in readonly structs. Otherwise the compiler will still create a defensive copy
– Panagiotis Kanavos
45 mins ago
Actually no. It is confirming that there is a performanc ebenefit. Given that IN was created in the performance run through the langauge, yes, that IS the reason. It ALLOWS an optmization (on readonly structs).
– TomTom
44 mins ago
1
@TomTom Again, which the question already covered. What it asks is, "So, then is the advantage just in larger structs, or is there some behind-the-scenes compiler optimization that makes it attractive elsewhere? If the latter, why shouldn't I make every parameter an in?" Note how it's not asking if it's actually beneficial for larger structs, or just when it's beneficial at all. It's just asking if it's beneficial for smaller structs (and then a follow up if yes). You haven't answer either question.
– Servy
43 mins ago
add a comment |Â
up vote
0
down vote
This is done because of the functional programming approach. One of the major principle is that function should not have side effects, which means it should not change values of the parameters and should return some value. In C# there was no way to pass structs(and value type) without being copied only by reference which allows changing of the value. In swift there is a hacky algorithm which copies struct (their collections are structs BTW) as long as method starts changing its values. People who use swift not all aware of the copy stuff. This is nice c# feature since it's memory efficient and explicit. If you look at what's new you will see that more and more stuff is done around structs and arrays in stack. And in statement is just necessary for these features. There are limitations mentioned in the other answers, but is not that essential for understanding where .net is heading.
answered 35 mins ago
Access Denied
4,14011340
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
in was recently introduced to the C# language.
in is actually a ref readonly. Generally speaking, there is only one use case where in can be helpful: high performance apps dealing with lots of large readonly structs.
Assuming you have:
readonly struct VeryLarge
public readonly long Value1;
public readonly long Value2;
// etc
and
void Process(in VeryLarge value)
In that case, the VeryLarge struct will be passed by-reference without creating of defensive copies when using this struct in the method, and the struct immutability is ensured by the compiler.
Note that passing a not-readonly struct with an in modifier will cause the compiler to create a defensive copy when using that struct in the method, which will negatively affect performance!
There is a really good MSDN blog entry which I recommend to carefully read.
If you would like to get some more historical background of in-introducing, you could read this discussion in the C# language's GitHub repository.
In general, most developers agree that introducing of in could be seen as a mistake. It's a rather exotic language feature and can only be useful in high-perf edge cases.
answered 49 mins ago
dymanoid
6,45421844
add a comment |Â
up vote
6
down vote
in was recently introduced to the C# language.
in is actually a ref readonly. Generally speaking, there is only one use case where in can be helpful: high performance apps dealing with lots of large readonly structs.
Assuming you have:
readonly struct VeryLarge
public readonly long Value1;
public readonly long Value2;
// etc
and
void Process(in VeryLarge value)
In that case, the VeryLarge struct will be passed by-reference without creating of defensive copies when using this struct in the method, and the struct immutability is ensured by the compiler.
Note that passing a not-readonly struct with an in modifier will cause the compiler to create a defensive copy when using that struct in the method, which will negatively affect performance!
There is a really good MSDN blog entry which I recommend to carefully read.
If you would like to get some more historical background of in-introducing, you could read this discussion in the C# language's GitHub repository.
In general, most developers agree that introducing of in could be seen as a mistake. It's a rather exotic language feature and can only be useful in high-perf edge cases.
answered 49 mins ago
dymanoid
6,45421844
add a comment |Â
up vote
6
down vote
up vote
6
down vote
in was recently introduced to the C# language.
in is actually a ref readonly. Generally speaking, there is only one use case where in can be helpful: high performance apps dealing with lots of large readonly structs.
Assuming you have:
readonly struct VeryLarge
public readonly long Value1;
public readonly long Value2;
// etc
and
void Process(in VeryLarge value)
In that case, the VeryLarge struct will be passed by-reference without creating of defensive copies when using this struct in the method, and the struct immutability is ensured by the compiler.
Note that passing a not-readonly struct with an in modifier will cause the compiler to create a defensive copy when using that struct in the method, which will negatively affect performance!
There is a really good MSDN blog entry which I recommend to carefully read.
If you would like to get some more historical background of in-introducing, you could read this discussion in the C# language's GitHub repository.
In general, most developers agree that introducing of in could be seen as a mistake. It's a rather exotic language feature and can only be useful in high-perf edge cases.
answered 49 mins ago
dymanoid
6,45421844
in was recently introduced to the C# language.
in is actually a ref readonly. Generally speaking, there is only one use case where in can be helpful: high performance apps dealing with lots of large readonly structs.
Assuming you have:
readonly struct VeryLarge
public readonly long Value1;
public readonly long Value2;
// etc
and
void Process(in VeryLarge value)
In that case, the VeryLarge struct will be passed by-reference without creating of defensive copies when using this struct in the method, and the struct immutability is ensured by the compiler.
Note that passing a not-readonly struct with an in modifier will cause the compiler to create a defensive copy when using that struct in the method, which will negatively affect performance!
There is a really good MSDN blog entry which I recommend to carefully read.
If you would like to get some more historical background of in-introducing, you could read this discussion in the C# language's GitHub repository.
In general, most developers agree that introducing of in could be seen as a mistake. It's a rather exotic language feature and can only be useful in high-perf edge cases.
answered 49 mins ago
dymanoid
6,45421844
edited 22 mins ago
answered 49 mins ago
dymanoid
6,45421844
answered 49 mins ago
dymanoid
6,45421844
answered 49 mins ago
dymanoid
6,45421844
6,45421844
add a comment |Â
add a comment |Â
up vote
2
down vote
There is. When passing a struct, the in keyword allows an optimization where the compiler only needs to pass a pointer, without the risk of the method changing the content. The last is critical — it avoids a copy operation. On large structs this can make a world of difference.
edited 48 mins ago
Joel Coehoorn
300k94487714
answered 51 mins ago
TomTom
48k363118
1
This is just repeating what the question already says, and doesn't answer the actual question it asks.
– Servy
45 mins ago
Only in readonly structs. Otherwise the compiler will still create a defensive copy
– Panagiotis Kanavos
45 mins ago
Actually no. It is confirming that there is a performanc ebenefit. Given that IN was created in the performance run through the langauge, yes, that IS the reason. It ALLOWS an optmization (on readonly structs).
– TomTom
44 mins ago
1
@TomTom Again, which the question already covered. What it asks is, "So, then is the advantage just in larger structs, or is there some behind-the-scenes compiler optimization that makes it attractive elsewhere? If the latter, why shouldn't I make every parameter an in?" Note how it's not asking if it's actually beneficial for larger structs, or just when it's beneficial at all. It's just asking if it's beneficial for smaller structs (and then a follow up if yes). You haven't answer either question.
– Servy
43 mins ago
add a comment |Â
up vote
2
down vote
There is. When passing a struct, the in keyword allows an optimization where the compiler only needs to pass a pointer, without the risk of the method changing the content. The last is critical — it avoids a copy operation. On large structs this can make a world of difference.
edited 48 mins ago
Joel Coehoorn
300k94487714
answered 51 mins ago
TomTom
48k363118
1
This is just repeating what the question already says, and doesn't answer the actual question it asks.
– Servy
45 mins ago
Only in readonly structs. Otherwise the compiler will still create a defensive copy
– Panagiotis Kanavos
45 mins ago
Actually no. It is confirming that there is a performanc ebenefit. Given that IN was created in the performance run through the langauge, yes, that IS the reason. It ALLOWS an optmization (on readonly structs).
– TomTom
44 mins ago
1
@TomTom Again, which the question already covered. What it asks is, "So, then is the advantage just in larger structs, or is there some behind-the-scenes compiler optimization that makes it attractive elsewhere? If the latter, why shouldn't I make every parameter an in?" Note how it's not asking if it's actually beneficial for larger structs, or just when it's beneficial at all. It's just asking if it's beneficial for smaller structs (and then a follow up if yes). You haven't answer either question.
– Servy
43 mins ago
add a comment |Â
up vote
2
down vote
up vote
2
down vote
There is. When passing a struct, the in keyword allows an optimization where the compiler only needs to pass a pointer, without the risk of the method changing the content. The last is critical — it avoids a copy operation. On large structs this can make a world of difference.
edited 48 mins ago
Joel Coehoorn
300k94487714
answered 51 mins ago
TomTom
48k363118
There is. When passing a struct, the in keyword allows an optimization where the compiler only needs to pass a pointer, without the risk of the method changing the content. The last is critical — it avoids a copy operation. On large structs this can make a world of difference.
edited 48 mins ago
Joel Coehoorn
300k94487714
answered 51 mins ago
TomTom
48k363118
edited 48 mins ago
Joel Coehoorn
300k94487714
edited 48 mins ago
Joel Coehoorn
300k94487714
edited 48 mins ago
Joel Coehoorn
300k94487714
300k94487714
answered 51 mins ago
TomTom
48k363118
answered 51 mins ago
TomTom
48k363118
answered 51 mins ago
TomTom
48k363118
48k363118
1
This is just repeating what the question already says, and doesn't answer the actual question it asks.
– Servy
45 mins ago
Only in readonly structs. Otherwise the compiler will still create a defensive copy
– Panagiotis Kanavos
45 mins ago
Actually no. It is confirming that there is a performanc ebenefit. Given that IN was created in the performance run through the langauge, yes, that IS the reason. It ALLOWS an optmization (on readonly structs).
– TomTom
44 mins ago
1
@TomTom Again, which the question already covered. What it asks is, "So, then is the advantage just in larger structs, or is there some behind-the-scenes compiler optimization that makes it attractive elsewhere? If the latter, why shouldn't I make every parameter an in?" Note how it's not asking if it's actually beneficial for larger structs, or just when it's beneficial at all. It's just asking if it's beneficial for smaller structs (and then a follow up if yes). You haven't answer either question.
– Servy
43 mins ago
add a comment |Â
1
This is just repeating what the question already says, and doesn't answer the actual question it asks.
– Servy
45 mins ago
Only in readonly structs. Otherwise the compiler will still create a defensive copy
– Panagiotis Kanavos
45 mins ago
Actually no. It is confirming that there is a performanc ebenefit. Given that IN was created in the performance run through the langauge, yes, that IS the reason. It ALLOWS an optmization (on readonly structs).
– TomTom
44 mins ago
1
@TomTom Again, which the question already covered. What it asks is, "So, then is the advantage just in larger structs, or is there some behind-the-scenes compiler optimization that makes it attractive elsewhere? If the latter, why shouldn't I make every parameter an in?" Note how it's not asking if it's actually beneficial for larger structs, or just when it's beneficial at all. It's just asking if it's beneficial for smaller structs (and then a follow up if yes). You haven't answer either question.
– Servy
43 mins ago
1
1
This is just repeating what the question already says, and doesn't answer the actual question it asks.
– Servy
45 mins ago
This is just repeating what the question already says, and doesn't answer the actual question it asks.
– Servy
45 mins ago
Only in readonly structs. Otherwise the compiler will still create a defensive copy
– Panagiotis Kanavos
45 mins ago
Only in readonly structs. Otherwise the compiler will still create a defensive copy
– Panagiotis Kanavos
45 mins ago
Actually no. It is confirming that there is a performanc ebenefit. Given that IN was created in the performance run through the langauge, yes, that IS the reason. It ALLOWS an optmization (on readonly structs).
– TomTom
44 mins ago
Actually no. It is confirming that there is a performanc ebenefit. Given that IN was created in the performance run through the langauge, yes, that IS the reason. It ALLOWS an optmization (on readonly structs).
– TomTom
44 mins ago
1
1
@TomTom Again, which the question already covered. What it asks is, "So, then is the advantage just in larger structs, or is there some behind-the-scenes compiler optimization that makes it attractive elsewhere? If the latter, why shouldn't I make every parameter an in?" Note how it's not asking if it's actually beneficial for larger structs, or just when it's beneficial at all. It's just asking if it's beneficial for smaller structs (and then a follow up if yes). You haven't answer either question.
– Servy
43 mins ago
@TomTom Again, which the question already covered. What it asks is, "So, then is the advantage just in larger structs, or is there some behind-the-scenes compiler optimization that makes it attractive elsewhere? If the latter, why shouldn't I make every parameter an in?" Note how it's not asking if it's actually beneficial for larger structs, or just when it's beneficial at all. It's just asking if it's beneficial for smaller structs (and then a follow up if yes). You haven't answer either question.
– Servy
43 mins ago
add a comment |Â
up vote
0
down vote
This is done because of the functional programming approach. One of the major principle is that function should not have side effects, which means it should not change values of the parameters and should return some value. In C# there was no way to pass structs(and value type) without being copied only by reference which allows changing of the value. In swift there is a hacky algorithm which copies struct (their collections are structs BTW) as long as method starts changing its values. People who use swift not all aware of the copy stuff. This is nice c# feature since it's memory efficient and explicit. If you look at what's new you will see that more and more stuff is done around structs and arrays in stack. And in statement is just necessary for these features. There are limitations mentioned in the other answers, but is not that essential for understanding where .net is heading.
answered 35 mins ago
Access Denied
4,14011340
add a comment |Â
up vote
0
down vote
This is done because of the functional programming approach. One of the major principle is that function should not have side effects, which means it should not change values of the parameters and should return some value. In C# there was no way to pass structs(and value type) without being copied only by reference which allows changing of the value. In swift there is a hacky algorithm which copies struct (their collections are structs BTW) as long as method starts changing its values. People who use swift not all aware of the copy stuff. This is nice c# feature since it's memory efficient and explicit. If you look at what's new you will see that more and more stuff is done around structs and arrays in stack. And in statement is just necessary for these features. There are limitations mentioned in the other answers, but is not that essential for understanding where .net is heading.
answered 35 mins ago
Access Denied
4,14011340
add a comment |Â
up vote
0
down vote
up vote
0
down vote
This is done because of the functional programming approach. One of the major principle is that function should not have side effects, which means it should not change values of the parameters and should return some value. In C# there was no way to pass structs(and value type) without being copied only by reference which allows changing of the value. In swift there is a hacky algorithm which copies struct (their collections are structs BTW) as long as method starts changing its values. People who use swift not all aware of the copy stuff. This is nice c# feature since it's memory efficient and explicit. If you look at what's new you will see that more and more stuff is done around structs and arrays in stack. And in statement is just necessary for these features. There are limitations mentioned in the other answers, but is not that essential for understanding where .net is heading.
answered 35 mins ago
Access Denied
4,14011340
This is done because of the functional programming approach. One of the major principle is that function should not have side effects, which means it should not change values of the parameters and should return some value. In C# there was no way to pass structs(and value type) without being copied only by reference which allows changing of the value. In swift there is a hacky algorithm which copies struct (their collections are structs BTW) as long as method starts changing its values. People who use swift not all aware of the copy stuff. This is nice c# feature since it's memory efficient and explicit. If you look at what's new you will see that more and more stuff is done around structs and arrays in stack. And in statement is just necessary for these features. There are limitations mentioned in the other answers, but is not that essential for understanding where .net is heading.
answered 35 mins ago
Access Denied
4,14011340
edited 18 mins ago
answered 35 mins ago
Access Denied
4,14011340
answered 35 mins ago
Access Denied
4,14011340
answered 35 mins ago
Access Denied
4,14011340
4,14011340
add a comment |Â
add a comment |Â
Travis Reed is a new contributor. Be nice, and check out our Code of Conduct.
Travis Reed is a new contributor. Be nice, and check out our Code of Conduct.
Travis Reed is a new contributor. Be nice, and check out our Code of Conduct.
Travis Reed is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52820372%2fwhy-would-one-ever-use-the-in-parameter-modifier-in-c%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Yes, there is a performance advantage.
refis used to pass structs by reference instead of copying them.inmeans the struct shouldn't be modified.– Panagiotis Kanavos
52 mins ago
@dbc no, this has nothing to do with interop
– Panagiotis Kanavos
50 mins ago
2
Performance for value types.The New “in†Keyword For C# 7.2
– Silvermind
50 mins ago
Detailed discussion here. Note the last warning:
It means that you should never pass a non-readonly struct as in parameter.– Panagiotis Kanavos
46 mins ago