Describe the solution you'd like
The more I use Rocks, the more I don't like having closed generics as a target for mocking. The resulting expectations type name is awkward, and then the developer has to specific each closed generic that they want to create. Using open generics is far cleaner.
Therefore, I'm thinking of not allowing closed generics to be specified, using either the generic or non-generic versions of the create and make attributes. This would be enforced with an analyzer.
Since this would be a breaking change, I may want to consider dropping the generic create and make attributes altogether. Especially if I do consider handling static abstract members in interfaces, since an interface with SAMs can't be passed into a type argument (at least you can't do that right now in .NET 8).
Along with this, make the analyzer that was created with this issue an error.
Describe alternatives you've considered
Let closed generics continue to work.
Describe the solution you'd like
The more I use Rocks, the more I don't like having closed generics as a target for mocking. The resulting expectations type name is awkward, and then the developer has to specific each closed generic that they want to create. Using open generics is far cleaner.
Therefore, I'm thinking of not allowing closed generics to be specified, using either the generic or non-generic versions of the create and make attributes. This would be enforced with an analyzer.
Since this would be a breaking change, I may want to consider dropping the generic create and make attributes altogether. Especially if I do consider handling static abstract members in interfaces, since an interface with SAMs can't be passed into a type argument (at least you can't do that right now in .NET 8).
Along with this, make the analyzer that was created with this issue an error.
Describe alternatives you've considered
Let closed generics continue to work.