C#11中IParsable<TSelf>泛型约束的必要性及相关疑问

为什么IParsable需要递归泛型约束？ #

IParsable的核心设计意图是让类型自身实现解析逻辑，最终返回该类型的实例。采用无约束的定义会直接破坏这个目标：

• 无约束的风险：无约束时，编译器允许写出完全不符合设计意图的代码，比如：

  // 合法但毫无意义的实现
  public class MyInt : IParsable<int>
  {
      public static int Parse(string s, IFormatProvider provider)
      {
          return int.Parse(s);
      }
  
      public static bool TryParse(string? s, IFormatProvider? provider, out int result)
      {
          return int.TryParse(s, provider, out result);
      }
  }
  

  这里MyInt实现的IParsable<int>返回的是int类型，而非MyInt自身，完全偏离了“类型自己解析自己”的需求，调用方使用时会产生逻辑混淆。

• 递归约束的作用：where TSelf : IParsable<TSelf>?这个递归约束强制要求，泛型参数TSelf必须是实现了IParsable<TSelf>的类型。也就是说，正确的实现必须把自身作为泛型参数传入，比如：

  // 符合设计意图的标准实现
  public class MyInt : IParsable<MyInt>
  {
      public int Value { get; set; }
  
      public static MyInt Parse(string s, IFormatProvider provider)
      {
          if (!TryParse(s, provider, out var result))
              throw new FormatException();
          return result;
      }
  
      public static bool TryParse(string? s, IFormatProvider? provider, out MyInt result)
      {
          if (int.TryParse(s, out var intValue))
          {
              result = new MyInt { Value = intValue };
              return true;
          }
          result = null;
          return false;
      }
  }
  

  这就保证了Parse方法返回的是当前类型的实例，完全匹配IParsable的设计目标。

• 关于边缘情况的说明：你提到的“仍允许TSelf为其他实现IParsable的类型”确实存在理论可能，但这种实现毫无实际价值——比如MyInt : IParsable<OtherType>的代码，MyInt的Parse方法返回的是OtherType，根本无法满足MyInt自身的解析需求，开发者不会这么写，调用时也会立刻发现逻辑错误，所以这种边缘情况不会影响约束的核心作用。

能否引入类似Delphi的ClassType的TSelf关键字？ #

C#目前没有内置的Self类型关键字来直接指代实现接口的自身类型，但当前的递归泛型约束就是官方和社区公认的替代方案：

• 递归约束where TSelf : IParsable<TSelf>虽然语法上略显冗余，但已经能稳定实现“强制类型绑定自身”的需求，是当前的最优解。
• 实际上C#语言团队曾经探讨过引入Self类型的可能性，但考虑到语法复杂度、现有代码兼容性以及当前方案已经覆盖绝大多数场景等因素，暂时没有将其纳入正式版本。如果未来有更强烈的场景需求，不排除会加入类似特性，但目前递归约束已经足够好用。

内容的提问来源于stack exchange，提问作者vc 74