Question

我在考虑而不是

result = result ?? defaultValue;

你可以写

result ?= defaultValue;

我不是说这是个好主意这个运营商有什么优势？这个运营商有哪些缺点？

Answer 1

我看到的最大潜在优势是它能够提供与+=等其他复合运营商相同的优势。请考虑以下

Method().Field = Method().Field ?? someValue;

如果Method()价格昂贵或有副作用，则此声明会出现两次。为了防止这种情况发生，你需要将其分解为2行

var temp = Method();
temp.Field = temp.Field ?? someValue;

如果你陷入这个位置，这可能有点单调乏味。如果?=具有+=的相同保证，左侧的副作用只发生一次，那么这条额外的线就没有必要了。

Method().Field += someValue; // Method() happens once
Method().Field ?= someValue; // Method() happens once

恕我直言，这是?=运营商提供的关键优势，仅仅是??。这很有价值，但我认为不值得添加语言

Answer 2

之前已经提出过这个建议，我将2011年愚人节的博客文章发布在将这个想法发挥到极致的基础上：

http://blogs.msdn.com/b/ericlippert/archive/2011/04/01/compound-assignment-part-two.aspx

与该帖子中提到的所有其他运营商不同，??=实际上有点有用。它的“直接”成本 - 设计，实施和记录，以及所有这些都需要花费时间，精力和金钱，这是没有用的。它肯定不能证明其“机会”成本是合理的 - 花在做一个相当愚蠢而不是特别有用的操作员上的时间，精力和金钱可以花在直接解决开发人员实际拥有的实际问题的功能上。

Answer 3

我认为这不值得。通常，您几乎总会这样做：

result = someSourceValue ?? defaultValue;

你的第二张表格是特例，很少使用。

在从某些源（如Web服务）读取值时，null合并运算符最有用，并且您希望将缺失值强制为零或其他一些默认值。数据几乎总是来自某个地方，然后去其他地方。

Answer 4

可能不是。我在C＃中只使用了几次空合并操作符，并且从不喜欢这样。 C＃的处理方式是编写显式的空检查，而不是无情的分配。（没有冒犯）

我相信很多人都希望拥有这个操作符，但我认为它根本不会对语言有所帮助。

这只是我的意见。

？=运营商有哪些优点或缺点？

4 个答案: