如果你看一下C#的这个版本,该特性带来了另一个特性,即ref局部变量。关于ref局部变量,也有一些考虑,ref再赋值(将一个局部变量“指向”另一个位置)以及ref局部变量默认只读,如何在所有可以引入变量的地方指定ref,区分普通赋值和ref赋值,类似这样的决策都需要在VB中解决,以便获得同样的生产能力。有大量的工作要做。
在VB中,工作量会更大,因为VB有额外的功能使用了ByRef,比如传递ByRef属性。VB编译器开发负责人Jared Parsons有一篇不错的博文,列举了许多在VB中使用ByRef的案例,可以说明这一点。返回一个ByRef属性,并在一个后期绑定的上下文中处理ByRef真得没有任何意义,因此, 与令人费解的ByRef参数相比,该语言对ByRef返回值的处理方式有所不同(而Jared现在得将更多的案例补充到那篇博文了)。那会给VB带来大量的困惑、语法和概念负担,因为C#增加了一项某一天可能用于编写一个集合类型的特性。
相反,我们采用一种不同的方法。简而言之,我们仅仅实现消费场景所需的特性,让你使用Slice(或者类似的返回ref的东西)就刚好可以完成你可以对数组进行的操作,除此之外,不提供任何额外的特性。当你使用索引指定一个数组元素时,你可以直接给它赋值,但你不能将数组元素的引用赋值给ref局部变量,并稍后再赋值给数组,你可以在那个索引指定的位置对值进行修改,你可以传递那个ByRef元素,但不能返回ByRef。也就是说,没有新语法,VB得到了保护。如果在VS2017发布之后,该语言的下一个版本发布之前,我们增加了Slice,而它作为一个集合类型,成了所有集合类型的终结者,一夜之间出现了数百万计的API返回ByRef类型。如果这个可能性微乎其微的噩梦永远不会发生,那么该语言就不会受此损害。这就是为什么它要那样设计。
(感兴趣的读者可以通过上面的链接阅读完整解释)
VB不是唯一一门这样做的语言。同样的考虑使得C#没有包含对XML库的支持,许多ASP.NET MVC开发人员都会希望它有这个特性。
查看英文原文:New Language Features in Visual Basic 15