You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
error CS8337: The first parameter of a 'ref' extension method 'SetVal' must be a value type or a generic type constrained to struct.
I propose removing the error for unconstrained generic parameters.
Motivation
The original motivation was to prevent people from writing somewhat shady extension methods that manipulated the receiver reference when the receiver is a reference type. This is a fine goal. But it's impeding a legitimate use case, which is providing an abstract API that works for both struct and reference type receivers, and appropriately propagates mutations. In these cases the caller will also have an unconstrained generic so they will not be able to determine whether they have a reference type or a value type, and thus not be able to satisfy the extension method struct constraint.
Detailed design
Remove the error for unconstrained generics.
Drawbacks
As mentioned, it could allow for some shady extension methods, although somewhat fewer since we still wouldn't permit known-reference types.
Alternatives
Something similar could maybe be done using static virtual methods. One of the main problems with using default interface methods for this purpose is that struct receivers are always boxed. In theory we could allow someone to write something like,
Note the this keyword in the parameter list of Set<T>. This could theoretically serve a similar purpose to the extension method -- it would provide a non-boxing default interface implementation.
Unresolved questions
N/A
Design meetings
The text was updated successfully, but these errors were encountered:
Summary
The following code produces an error in C#:
Specifically, the error,
I propose removing the error for unconstrained generic parameters.
Motivation
The original motivation was to prevent people from writing somewhat shady extension methods that manipulated the receiver reference when the receiver is a reference type. This is a fine goal. But it's impeding a legitimate use case, which is providing an abstract API that works for both struct and reference type receivers, and appropriately propagates mutations. In these cases the caller will also have an unconstrained generic so they will not be able to determine whether they have a reference type or a value type, and thus not be able to satisfy the extension method struct constraint.
Detailed design
Remove the error for unconstrained generics.
Drawbacks
As mentioned, it could allow for some shady extension methods, although somewhat fewer since we still wouldn't permit known-reference types.
Alternatives
Something similar could maybe be done using
static virtual
methods. One of the main problems with using default interface methods for this purpose is that struct receivers are always boxed. In theory we could allow someone to write something like,Note the
this
keyword in the parameter list ofSet<T>
. This could theoretically serve a similar purpose to the extension method -- it would provide a non-boxing default interface implementation.Unresolved questions
N/A
Design meetings
The text was updated successfully, but these errors were encountered: