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

Question

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

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

...我的理解是我的ContactList类型需要定义一个带有Add两个string参数的方法:

public void Add(string name, string email);

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

所以几乎看起来使用这个集合初始化器语法(有一个Add方法,因此是一个可变集合)的主要要求与它最有用的典型情况不一致.

我确信我没有像C#设计团队那样考虑这个问题; 看起来这个语法可能会有不同的规则,这些规则可以与其典型的使用场景进行更好的网格划分.

我离开基地吗？是否希望使用{ }语法来初始化固定大小的集合,这不像我想的那么常见？还有哪些其他因素可能会影响我对这种语法的要求的制定,而我根本就没有考虑过？

Answer 1

我确信我没有像C#设计团队那样考虑这个问题; 看起来这个语法可能会有不同的规则,这些规则可以与其典型的使用场景进行更好的网格划分.

你的分析非常好; 关键问题是上述陈述中的最后三个字.实际的典型使用场景是什么？

由集合初始化器的典型使用场景推动的设计目标是使表达式语法中的现有集合类型初始化成为可能,以便集合初始化器可以嵌入查询理解中或转换为表达式树.

其他每种情况的优先级都较低; 该功能存在,因为它有助于LINQ工作.

C#3编译器团队是Visual Studio/.NET发布的"长极" - 我们在任何团队的日程安排上都有大部分工作时间,这意味着我们每天都会延迟,产品会延迟.我们想为所有人按时发运优质产品,完美是善的敌人.是的,这个功能略显笨重,并没有完全做到你想要的所有内容,但更重要的是让它变得坚固并经过LINQ测试,而不是让它适用于一大堆不可变的集合类型甚至存在.

如果从第一天开始就将这个功能设计到语言中,而框架类型仍在不断发展,那么我确信事情会有所不同.正如我们在本网站的其他地方所讨论的那样,我非常希望能够拥有一次写入多次读取固定大小的数组值.定义一个公共模式以提供一堆状态来初始化任意不可变集合会很不错.你是对的,集合初始化器语法对于这样的事情是理想的.

类似的功能列在潜在的未来hyptothetical语言版本列表中,但在列表中不是真正的高.换句话说,在我们认为对于不可变集合初始化的语法糖太难之前,让我们首先得到异步/等待.