Disallow non-readonly methods and properties on "in" value types

[dkonik]

The in keyword is very close to being incredibly useful. Unlike ref, it allows you to implement interfaces (like IComparable, etc) on structs without making copies, which is great for large structs, etc. However, it has a major flaw in that it is very easy for it to silently cause methods which take structs via in to become more expensive (in terms of the number of copies) than just passing the struct by value (without in).

It's incredibly easy to forget to mark properties and methods as readonly, especially in a large code base with many developers working on different aspects, and thus cause the compiler to create defensive copies without any warning or indication.

If the entire point of the in keyword for value types is to avoid making copies when it's not necessary, would it not be better to just fail to allow programmers to call non-readonly methods and properties on a struct passed via the in keyword.

[tannergooding]

https://github.com/SergeyTeplyakov/ErrorProne.NET is one possible solution as it will flag many types of hidden copies.

I'd appreciate if we could get a warning wave for this as well since it can be difficult or near impossible for analyzers to catch every kind of hidden copy.

[theunrepentantgeek]

This would be a breaking change, and the LDM have historically been extremely reticent to take those on.

Except in extreme cases, upgrading the compiler should not break existing code that worked.

This is not an extreme case.

Using an Analyzer is the correct solution for this situation because it allows you to opt into the very specific rules you want for your situation without imposing them as a tax on the vast majority of project that just don't care.

[RikkiGibson]

I think it would be fine to catch these either with a community analyzer, or an analyzer built-in to the SDK which is controlled by a warning wave, or in the compiler itself in a warning wave. cc @jmarolf

[qrli]

Personally, I think it should be compiler warning, other than optional analyzer. As in is designed for performance, failed to achieve that goal typically means bug in source code.