Generic constraint where T : readonly struct

[AustinBryan]

Right now, doing this doesn't work:

public class<T> where T : readonly struct
{
}

This would be useful because, when using in parameters and larger structs, there are performance impacts from using the in parameter due to the defensive copy. This doesn't happen with readonly structs.

Therefore, it would be useful constraint so we know, in the scope of the class or method, we can use in parameters and benefit from the performance gains.

[jnm2]

@AustinBryan How would this interact with existing compilers and runtimes?

[sonnemaf]

Maybe you can omit the 'struct' keyword from the constraint and only write 'readonly'.

public class<T> where T : readonly 
{
}

readonly is (for now) only possible for structs.

[kindermannhubert]

Is there any progress on this? What is language team's opinion?
I know it would not cover everything (e.g. Readonly Instance Members) but I believe that readonly structs passed by in would be be much more common then nonreadonly structs with readonly member.
Would be really nice to have this constraint. Otherwise readonly attribute of structs is completely ignored when using generics.

[tannergooding]

Therefore, it would be useful constraint so we know, in the scope of the class or method, we can use in parameters and benefit from the performance gains.

Just restricting to where T : readonly struct would not provide this information. C# 8 added support for readonly members and this allows you to avoid the defensive copy even when calling instance methods of mutable structs (e.g. Vector2/3/4, Matrix4x4, etc).

[WizardBrony]

Therefore, it would be useful constraint so we know, in the scope of the class or method, we can use in parameters and benefit from the performance gains.

Just restricting to where T : readonly struct would not provide this information.

Could you please explain why a readonly struct constraint would not provide this information? For example, if the constraint was where T : readonly struct, IInterface, even if the struct T implemented IInterface explicitly, the compiler still requires that the implementation does not modify T's state. I understand how readonly members can be used to avoid a defensive copy. I just don't understand why readonly struct wouldn't do the same.

[tannergooding]

readonly struct would provide that information for some types, specifically for readonly structs

It would completely miss that information for any other type which might be mutable but only for specific methods. For example, Vector4 is a mutable struct and always must be due to back-compat (it exposes a public field), but every method it exposes is readonly.

If you are looking to avoid the defensive copies, an analyzer like ErrorProne.NET will solve the same problem, but will correctly flag all the scenarios without needing to touch the language.

[WizardBrony]

readonly struct would provide that information for some types, specifically for readonly structs

It would completely miss that information for any other type which might be mutable but only for specific methods.

Sure, that makes perfect sense for that example. And in my example, my assumption is that avoiding the defensive copies would essentially amount to making overloads for each readonly struct that implements a particular IInterface member (which considering they're structs should not be very many types).