Is Changing A Generic Parameter's Name A Breaking Change

Question

When updating a library, it's important to accurately communicate any breaking changes. Unfortunately there are a number of different kinds of breaking changes in C#, and some of them are quite subtle.

The obvious ones are things like changing the names of types or type members.

The subtle ones are things like adding a new default parameter (binary compatibility is broken, but source compatibility is preserved), or renaming a parameter (binary compatibility is maintained, but source compatibility is broken).

I am unsure about renaming generic parameters.

For example, is there a case where changing:

public class Foo<T>
{
  public T Bar(){ /* something */ }
}

to

public class Foo<TMoreDescriptive>
{
  public TMoreDescriptive Bar(){ /* something */ }
}

between releases of a library could break a consumer?

Answer 1

No, there is no such case.

Changing the name of a generic type parameter is no more a breaking change than changing the name of a method parameter is. According to the C# Programming Guide, generic types are replaced the moment the consumer instantiates the class with a generic type argument - at no point is the consumer given the original type parameter's name except via documentation or an IntelliSense-like feature.

The guide also mentions that generic type parameters are available via reflection - this is likely the only vector by which your consumer is able to programmatically inspect the name change, similar to method parameters.