c# - 为什么 { } 初始化需要 Add 方法？

Question

要使用这样的初始化语法:

var contacts = new ContactList
{
    { "Dan", "dan.tao@email.com" },
    { "Eric", "ceo@google.com" }
};

...我的理解是我的 ContactList 类型 would need to define an Add method需要两个 string 参数:

public void Add(string name, string email);

让我有点困惑的是 { } 初始化语法似乎在创建只读或固定大小的集合时最有用。毕竟它是为了模仿数组 的初始化语法，对吧？ (好吧，所以数组不是只读的；但它们是 固定大小。)当然它只能在编译时知道集合的内容(至少是元素的数量)时使用.

因此，使用此集合初始化器语法(具有 Add 方法，因此是一个可变集合)的主要要求似乎与它最有用的典型情况不一致.

我敢肯定，我没有像 C# 设计团队那样对此事投入过多的思考；似乎这种语法可能有不同的规则，可以更好地适应其典型的使用场景。

我在这里离基地很远吗？使用 { } 语法来初始化固定大小的集合的愿望并不像我想象的那么普遍吗？还有哪些其他因素可能影响了我根本没有想到的这种语法要求的制定？

Answer 1

I'm sure I haven't put as much thought into this matter as the C# design team; it just seems that there could have been different rules for this syntax that would have meshed better with its typical usage scenarios.

你的分析很好；关键问题是上面那句话的最后三个字。实际的典型使用场景是什么？

集合初始化器的典型使用场景所激发的设计目标是使现有集合类型的初始化可以在表达式语法中实现这样集合初始值设定项可以嵌入到查询理解中或转换为表达式树。

所有其他场景的优先级都较低； 该功能之所以存在，是因为它有助于使 LINQ 正常工作。

C# 3 编译器团队是该版本 Visual Studio/.NET 的“长杆”——我们在所有团队的日程安排中工作的时间最多，这意味着我们延迟的每一天，产品都会延迟。我们希望为你们所有人按时交付优质产品，而完美是优秀的敌人。是的，此功能有点笨拙，并不能完全满足您的所有需求，但更重要的是让它可靠并针对 LINQ 进行测试，而不是使其适用于大量不可变的集合类型甚至存在。

如果从第一天起就将此功能设计到语言中，而框架类型仍在发展，我相信事情会有所不同。正如我们在本网站的其他地方所讨论的那样，我非常希望有一个一次写入多次读取的固定大小的值数组。最好定义一个通用模式来提供一堆状态来初始化任意不可变集合。你是对的，集合初始化语法对于这样的事情来说是理想的。

像这样的功能在潜在的 future 假设语言版本的列表中，但在列表中的位置并不高。换句话说，让我们先了解 async/await，然后再认真考虑用于不可变集合初始化的语法糖。