【发布时间】:2018-04-06 23:58:29
【问题描述】:
如果我们想要一个 IEnumerable<T> 代表两个 IEnumberable<T>s 的串联,我们可以使用 LINQ Concat() 方法。
例如:
int[] a = new int[] { 1, 2, 3 };
int[] b = new int[] { 4, 5 };
foreach (int i in a.Concat(b))
{
Console.Write(i);
}
当然输出12345。
我的问题是,为什么 Concat() 没有重载只接受 T 类型的单个元素,这样:
int[] a = new int[] { 1, 2, 3 };
foreach (int i in a.Concat(4))
{
Console.Write(i);
}
将编译并生成输出:1234?
围绕该问题进行谷歌搜索会引发几个 SO 问题,其中公认的答案表明,在寻求实现这一目标时,最好的方法是简单地执行 a.Concat(new int[] {4})。在我看来,这很好(ish)但有点“不干净”,因为:
- 声明一个新数组可能会对性能造成影响(尽管这几乎可以忽略不计)
- 只是看起来不像
a.Concat(4)那么简洁、易读和自然
有人知道为什么不存在这样的重载吗?
另外,假设我的谷歌搜索没有让我失望 - 没有类似的 LINQ 扩展方法采用 T 类型的单个元素。
(我知道滚动自己的扩展方法来产生这种效果非常容易 - 但这不会让这个省略更加奇怪吗?我怀疑它的省略是有原因的,但无法想象它会发生什么是吗?)
更新:
承认以意见为基础的投票结束了这一点 - 我应该澄清一下,我并不是在征求人们对这是否是对 LINQ 的一个很好的补充的意见。
更多我正在寻求了解为什么它不是 LINQ 的一部分的事实原因。
【问题讨论】:
-
遗漏不一定是有原因的。入选必须有充分的理由。
-
底线是:我们只能猜测。除非来自 C# 语言规范组的人插话。所以:基于意见,100%。不相关,因为我们不知道。猜测是没有答案的。
-
它不是 LINQ 的一部分的事实原因只能由语言设计者来回答。
-
“我正在寻求了解为什么它还不是 LINQ 的一部分的事实原因。” -- 这对你来说怎么样?到目前为止,已经发布了六个不同的答案,not one 包含任何关于为什么这不是 LINQ 的一部分的事实信息。他们都是意见。这正是存在这种密切原因的原因;因为这种性质的问题会引起很多意见,但没有事实。
-
我对这个问题没有强烈的看法。我(经常!)鼓励人们做的是不要问“为什么”,或者更糟糕的是,“为什么不”关于 SO 的问题;很难令人满意地回答它们。 “为什么”的答案通常是“设计团队对此进行了数小时/数天/数周的辩论,我们没有那次谈话的记录”,我们已经看到每个“为什么不?”有相同的答案:该功能开始时未实现并留在那里,因为每个人都忙于其他功能。坚持“如何”和“什么”的问题。
标签: c# linq ienumerable