result = result ?? defaultValue;
您可以编写
result ?= defaultValue;
我不是在说这是个好主意。
这个操作符有哪些优势?
这个操作符有哪些缺点?
result = result ?? defaultValue;
您可以编写
result ?= defaultValue;
我不是在说这是个好主意。
这个操作符有哪些优势?
这个操作符有哪些缺点?
我认为最大的潜在优势是它能够提供其他复合运算符(如+=
)相同的优点。请考虑以下内容:
Method().Field = Method().Field ?? someValue;
如果Method()
很昂贵或者有副作用,这个语句会导致它发生两次。为了防止这种情况发生,你需要将其分成两行。
var temp = Method();
temp.Field = temp.Field ?? someValue;
如果你陷入这种困境,这可能会有点繁琐。 如果?=
具有与+=
相同的保证,即左侧的副作用仅发生一次,则不需要额外的一行。
Method().Field += someValue; // Method() happens once
Method().Field ?= someValue; // Method() happens once
在我看来,相对于简单的??
操作符,使用?=
操作符提供了关键的优势。虽然它很有价值,但我认为这并不值得将其添加到语言中。
这个想法之前就有人提出过,而我在2011年愚人节博客文章中将这个想法推向了极致:
http://blogs.msdn.com/b/ericlippert/archive/2011/04/01/compound-assignment-part-two.aspx
与上述文章中提到的所有其他运算符不同,??=
运算符实际上会稍微有点用处。但它的“直接”成本(设计、实现、文档编写等需要时间、精力和资金)肯定不能证明其价值。而且,它绝对不能证明其“机会”成本——将时间、精力和资金花费在一个相当愚蠢且不特别有用的操作符上,可以用来直接解决开发人员实际面对的问题。
可能不会。我只在C#中使用过null合并运算符几次,而且从未像这样使用过。C#的做法是编写显式的空检查,而不是随意赋值。(无意冒犯)
我相信很多人都想要这个运算符,但我认为它对语言没有任何好处。
这只是我的观点。
?=
加入到混乱的 ??
或 ?:
中,这让很多人都不理解。 - Yuck我认为这不值得。通常情况下,你几乎总是会做类似以下的事情:
result = someSourceValue ?? defaultValue;
你的第二个表单是一个特殊情况,很少会被使用。
当从某些源(如 Web 服务)读取值并希望将缺失值强制为零或其他默认值时,空合并运算符最有用。数据几乎总是来自某个地方,并且要去往其他地方。
+=
,-=
,*=
- Robert Harvey