.Net 隐式转换指南

Question

关于何时可以、应该或不应该定义用户定义的隐式转换的一般准则是什么？

我的意思是，例如，“隐式转换永远不应该丢失信息”，“隐式转换永远不应该抛出异常”，或者“隐式转换永远不应该实例化新对象”。 我很确定第一个是正确的，第三个不是（或者我们只能隐式转换为结构），而我不知道第二个。

Answer 1

第一个并不像您想象的那么简单。 这是一个例子：

using System;

class Test
{
    static void Main()
    {
        long firstLong = long.MaxValue - 2;
        long secondLong = firstLong - 1;

        double firstDouble = firstLong;
        double secondDouble = secondLong;

        // Prints False as expected
        Console.WriteLine(firstLong == secondLong);

        // Prints True!
        Console.WriteLine(firstDouble == secondDouble);        
    }
}

就我个人而言，我很少创建自己的隐式转换。 我对框架中的内容感到非常满意，但我很少觉得添加自己的内容会让生活变得更好。 （顺便说一句，一般值类型也是如此。）

编辑：只是为了实际回答一下这个问题，可能值得阅读 转换运算符是 Microsoft 类库设计指南的一部分。

Answer 2

我绝对同意第一个观点——大多数情况下是第二个观点（“永不言败”），但不会对第三个观点感到兴奋； 除此之外，它在结构和类之间造成了不必要的区别。 在某些情况下，进行隐式转换可以极大地简化调用约定。

对于显式转换，一切皆有可能。

不过，您并不经常需要编写转换运算符。 在许多情况下，显式运算符更有用，因为如果条件不正确，它们可能会中断（例如，使用 Nullable，如果它们没有值） 。

Answer 3

如果您只支持自己类型的对象之间的隐式转换，我建议您应该决定哪些“公理”应该应用于此类转换（例如，决定如果 a==b< /code>、b==c 和 a==c 都是合法的，其中两个为真，第三个也必须为真），然后识别使这些公理成立的最有用的转换集。 我在我的博客上讨论了四个有用的公理：http:// supercatnet.blogspot.com/2013/09/axioms-of-implicit-type-conversion.html（不幸的是，.NET Framework 包含违反所有四个的转换，同时不允许不必要的转换）。

需要考虑的重要一点是，在大多数情况下，与不精确类型的隐式转换相比，从不精确类型进行隐式转换会带来更小的意外风险，但有一个值得注意的例外：将更精确类型的某些内容提供给具有重载的方法或运算符，该重载同时采用更精确类型和可以转换为不太精确的类型，某种程度的“令人惊讶”的行为几乎是不可避免的，除非可以使隐式转换变得不可能[例如，如果程序员编写 if (someLong == someFloat) 的行为可能会令人惊讶，但这并不是因为隐式 long 的精度损失float 转换令人惊讶，而是因为人们可能想要通过至少六种不同的方式来比较 long 和 float(*)，和 any 意味着编译器可能会附加直接比较，这会让那些期待其他东西的人感到惊讶。 据我所知，避免这种惊讶的唯一解决方案是提供重载来显式覆盖所有不明确的情况，并用 [Obsolete()] 标记标记它们。 这样做可能会有些尴尬，但会带来能够满足所有四个公理的巨大优势。

(*) 程序员可能有意测试 long 是否等于四舍五入到最接近的浮点值、向零截断或向负无穷大取整； 或者，程序员可能想要测试 float 是否代表 long，float 和 long< /code> 具有相同的标称值，或者 float 和 long 是否都会转换为相同的 double。

Answer 4

导致我问这个问题的边缘案例违反了第二个案例。 也就是说，我有一个 Lazy类（不是每个人？）并开始思考我是否不应该提供对 T 的隐式转换。我的直觉是说是，当前版本确实如此，但我不太确定。