在我看来，与 TypeConverter 相比，实现隐式运算符非常容易，因此我假设它们不等效，因为框架中普遍存在 TypeConverters（请参阅任何扩展 FrameworkElement 的内容）。
但是为什么呢？创建 string->object 和 object->string 隐式运算符并利用序列化中的那些（XML 和 XAML）不是更容易吗？
是雅格尼吗？单一责任？因为不能在接口中指定运算符重载？
【问题讨论】：
标签： .net operator-overloading implicit typeconverter
类型转换器比看起来要复杂得多；类型转换器可以访问有关转换的上下文的一系列元数据 - 例如，所涉及的属性和对象。这用于为每个场景提供自定义选项（想想：链接的下拉列表，即国家/县/城市/等）。您还可以在每个属性的基础上指定类型转换器，我在很多地方使用它来提供对各种字符串属性的不同处理。操作员会一视同仁地对待所有字符串。
隐式运算符只知道正在转换的值，但具有更大的编译时支持。
或者其他方式：
TypeConverter 是框架支持的框架特性；
运算符（主要）是具有语言支持的语言功能
要添加更多 - 类型转换器（尽管名称）不只是转换：
PropertyGrid 上扩展属性）PropertyGrid 上的下拉选项）请注意，它们不仅用于PropertyGrid，还用于更多地方；-p
【讨论】：
我不是这方面的专家。
但乍一看，它看起来像 - 您可以在原始类之外提供转换器（与隐式运算符相反）&也许您可以为同一事物定义多个 TypeConverter 类（如果您想为同一事物获得不同的视图值）。
【讨论】：
隐式运算符很好，但它们也可能令人困惑。我认为，当您需要从一种类型转换为另一种类型时，最好是明确的，因为毫无疑问会发生什么。
此外，隐式运算符似乎是为非常相似的事物保留的，并且隐式转换是直观的。但我想这都是主观的，请使用您的最佳判断。
【讨论】：
只是好奇：TypeConverters 可以与 Visual Studio 设计器一起使用，因此，如果您为 Lists 或 Arrays 等属性提供正确的 TypeConverter，则可以通过设计器设置它们。隐式运算符是否也提供此服务？如果不是，我怀疑这回答了您的问题：它们在框架中使用，以便使用这些项目的控件可以与设计器一起使用。
【讨论】：