原文地址:http://code.msdn.microsoft.com/Project/Download/FileDownload.aspx?ProjectName=csharpfuture&DownloadId=3550(Word格式,需接受许可协议并下载。)
译文地址:http://www.cnblogs.com/AndersLiu/archive/2008/11/03/1325148.html
原著作者:Mads Torgersen, C# Language PM
翻译:Anders Liu
摘要:Microsoft Visual C# 3.0作为Visual Studio 2008的一部分发布以来已经快一年了。在VS Managed Languages团队,我们一直努力创建该语言的下一个版本(没什么惊喜,就是C# 4.0),而这个文档是我们现在所看到的、计划中的语言特性的第一个公开描述。
It is now close to a year since Microsoft Visual C# 3.0 shipped as part of Visual Studio 2008. In the VS Managed Languages team we are hard at work on creating the next version of the language (with the unsurprising working title of C# 4.0), and this document is a first public description of the planned language features as we currently see them.
Microsoft Visual C# 3.0作为Visual Studio 2008的一部分发布以来已经快一年了。在VS Managed Languages团队,我们一直努力创建该语言的下一个版本(没什么惊喜,就是C# 4.0),而这个文档是我们现在所看到的、计划中的语言特性的第一个公开描述。
Please be advised that all this is in early stages of production and is subject to change. Part of the reason for sharing our plans in public so early is precisely to get the kind of feedback that will cause us to improve the final product before it rolls out.
请记住本文内容都是针对产品早期的,而且将来会改变。这么早地共享我们的计划,一部分原因是为了获取某些反馈,这些反馈会让我们在产品最终发布出来之前改进它。
Simultaneously with the publication of this whitepaper, a first public CTP (community technology preview) of Visual Studio 2010 is going out as a Virtual PC image for everyone to try. Please use it to play and experiment with the features, and let us know of any thoughts you have. We ask for your understanding and patience working with very early bits, where especially new or newly implemented features do not have the quality or stability of a final product. The aim of the CTP is not to give you a productive work environment but to give you the best possible impression of what we are working on for the next release.
与该白皮书一同发布的还有Visual Studio 2010的第一个公开的CTP(社区技术预览),它通过Virtual PC映像发布,任何人都可以试用。请使用这个CTP来把玩和试验这些特性,并让我们知道您的想法。我们希望知道您对这个早期产品的理解和不满,尤其是新添加的实现特性是否不具备最终产品应有的质量和稳定性。这个CTP的目的不是为您提供一个高生产力的工作环境,而是让您对我们正在为下一个发布版做些什么有个印象。
The CTP contains a number of walkthroughs, some of which highlight the new language features of C# 4.0. Those are excellent for getting a hands-on guided tour through the details of some common scenarios for the features. You may consider this whitepaper a companion document to these walkthroughs, complementing them with a focus on the overall language features and how they work, as opposed to the specifics of the concrete scenarios.
该CTP包含了大量的演练,其中一些着重于C# 4.0的语言新特性。要详细了解这些特性的常用场景,这些演练是绝好的上手教程。您可以认为该白皮书是这些演练的伴随文档,全面地介绍了语言的特性和工作原理,而那些演练则是介绍具体的场景。
The major theme for C# 4.0 is dynamic programming. Increasingly, objects are “dynamic” in the sense that their structure and behavior is not captured by a static type, or at least not one that the compiler knows about when compiling your program. Some examples include
C# 4.0的主要主题是动态编程。对象的意义变得越来越“动态”,它们的结构和行为无法通过静态类型来捕获,或者至少编译器在编译程序时无法得知对象的结构和行为。例如——
While C# remains a statically typed language, we aim to vastly improve the interaction with such objects.
尽管C#依然是静态类型语言,但我们的目的是改善它与这些对象的交互。
A secondary theme is co-evolution with Visual Basic. Going forward we will aim to maintain the individual character of each language, but at the same time important new features should be introduced in both languages at the same time. They should be differentiated more by style and feel than by feature set.
另一个次要主题是与Visual Basic协同进步(co-evolution)。将来我们希望仅维护每种语言单独的特征,而重要的新特性会同时引入两种语言。它们的区别仅仅是风格和感觉上的,而不在于特性集方面。
The new features in C# 4.0 fall into four groups:
C# 4.0中的新特性分为四组——
Dynamic lookup allows you to write method, operator and indexer calls, property and field accesses, and even object invocations which bypass the C# static type checking and instead gets resolved at runtime.
动态查找允许在编写方法、运算符和索引器调用、属性和字段访问甚至对象调用时,绕过C#静态类型检查,而在运行时进行解析。
Parameters in C# can now be specified as optional by providing a default value for them in a member declaration. When the member is invoked, optional arguments can be omitted. Furthermore, any argument can be passed by parameter name instead of position.
现在C#中的参数可以通过在成员声明中为其提供默认值来指名它是可选的。在调用该成员时,可选参数可以忽略。另外,在传入任何参数时都可以按照参数名而不是位置进行传递。
Dynamic lookup as well as named and optional parameters both help making programming against COM less painful than today. On top of that, however, we are adding a number of other small features that further improve the interop experience.
动态查找以及命名参数和可选参数都有助于使针对COM的编程不再像今天这样痛苦。在这些特性之上,我们还添加了大量其他小特性,进一步改善了互操作体验。
It used to be that an IEnumerable
过去,IEnumerable
Dynamic lookup allows you a unified approach to invoking things dynamically. With dynamic lookup, when you have an object in your hand you do not need to worry about whether it comes from COM, IronPython, the HTML DOM or reflection; you just apply operations to it and leave it to the runtime to figure out what exactly those operations mean for that particular object.
动态查找可以用统一的方式来动态调用成员。有了动态查找,当你拿到一个对象时,不用管它是来自于COM还是IronPython、HTML DOM或是反射;只需要对其进行操作即可,运行时会帮你指出针对特定的对象,这些操作的具体意义。
This affords you enormous flexibility, and can greatly simplify your code, but it does come with a significant drawback: Static typing is not maintained for these operations. A dynamic object is assumed at compile time to support any operation, and only at runtime will you get an error if it wasn’t so. Oftentimes this will be no loss, because the object wouldn’t have a static type anyway, in other cases it is a tradeoff between brevity and safety. In order to facilitate this tradeoff, it is a design goal of C# to allow you to opt in or opt out of dynamic behavior on every single call.
这给你带来了巨大的灵活性,并能极大程度地精简代码,但它伴随着一个巨大的缺点——不会为这些操作维护静态类型。在编译时,会假设动态对象支持任何操作,而如果它不支持某个操作,则只有到运行时才能得到错误。有的时候这不会有任何损失,因为对象根本不具有静态类型,而且他情况下必须在简洁和安全之间进行权衡。为了帮助进行权衡,C#的一个设计目标就是允许在每个单独的调用中选择是否使用动态行为。
C# 4.0 introduces a new static type called dynamic. When you have an object of type dynamic you can “do things to it” that are resolved only at runtime:
C# 4.0引入了一个新的静态类型,称为dynamic。当你拥有了一个dynamic类型的对象后,你“对他做的事情”只会在运行时进行解析——
The C# compiler allows you to call a method with any name and any arguments on d because it is of type dynamic. At runtime the actual object that d refers to will be examined to determine what it means to “call M with an int” on it.
C#编译器允许你使用任何参数在d上调用一个方法,因为它的类型是dynamic。运行时会检查d的实际类型,并检测在它上面“用一个int调用M”是什么意思。
The type dynamic can be thought of as a special version of the type object, which signals that the object can be used dynamically. It is easy to opt in or out of dynamic behavior: any object can be implicitly converted to dynamic, “suspending belief” until runtime. Conversely, there is an “assignment conversion” from dynamic to any other type, which allows implicit conversion in assignment-like constructs:
可以认为dynamic类型是object类型的一个特殊版本,指出了对象可以动态地使用。选择是否使用动态行为很简单——任何对象都可以隐式转换为dynamic,“挂起信任”直到运行时。反之,从dynamic到任何其他类型都存在“赋值转换”,可以类似于赋值的结构中进行隐式转换——
Not only method calls, but also field and property accesses, indexer and operator calls and even delegate invocations can be dispatched dynamically:
不仅是方法调用,字段和属性访问、索引器和运算符调用甚至委托调用都可以动态地分派——
The role of the C# compiler here is simply to package up the necessary information about “what is being done to d”, so that the runtime can pick it up and determine what the exact meaning of it is given an actual object d. Think of it as deferring part of the compiler’s job to runtime.
C#编译器在这里的角色就是打包有关“在d上做什么”的必要信息,使得运行时可以获取这些信息并检测对于实际对象d这些操作的确切含义。可以认为这是将编译器的部分工作延迟到了运行时。
The result of any dynamic operation is itself of type dynamic.
任何动态操作的结果本身也是dynamic类型的。
At runtime a dynamic operation is dispatched according to the nature of its target object d:
在运行时,动态操作将根据目标对象d的本质进行分派——
If d is a COM object, the operation is dispatched dynamically through COM IDispatch. This allows calling to COM types that don’t have a Primary Interop Assembly (PIA), and relying on COM features that don’t have a counterpart in C#, such as indexed properties and default properties.
如果d是一个COM对象,则操作通过COM IDispatch进行动态分派。这允许调用没有主互操作程序集(Primary Interop Assembly,PIA)的COM类型,并依赖C#中没有对应概念的COM特性,如索引属性和默认属性。
If d implements the interface IDynamicObject d itself is asked to perform the operation. Thus by implementing IDynamicObject a type can completely redefine the meaning of dynamic operations. This is used intensively by dynamic languages such as IronPython and IronRuby to implement their own dynamic object models. It will also be used by APIs, e.g. by the HTML DOM to allow direct access to the object’s properties using property syntax.
如果d实现了IDynamicObject接口,则请求d自身来执行该操作。因此通过实现IDynamicObject接口,类型可以完全重新定义动态操作的意义。这在动态语言——如IronPython和IronRuby——中大量使用,用于实现他们的动态对象模型。API也会使用这类对象,例如HTML DOM允许直接使用属性语法来访问对象的属性。
Otherwise d is a standard .NET object, and the operation will be dispatched using reflection on its type and a C# “runtime binder” which implements C#’s lookup and overload resolution semantics at runtime. This is essentially a part of the C# compiler running as a runtime component to “finish the work” on dynamic operations that was deferred by the static compiler.
除此之外,则d是一个标准的.NET对象,操作是通过在其类型上进行反射来分派的,C#的“运行时绑定器(runtime binder)”实现了运行时的C#查找和重载解析。其背后的本质是将C#编译器作为运行时组件运行,来“完成”被静态编译器延迟的动态操作。
Assume the following code:
考虑下面的代码——
Because the receiver of the call to M is dynamic, the C# compiler does not try to resolve the meaning of the call. Instead it stashes away information for the runtime about the call. This information (often referred to as the “payload”) is essentially equivalent to:
由于对M进行调用的接受者是dynamic类型的,C#编译器不会试图解析该调用的意义。而是将有关该调用的信息存储起来,供运行时使用。该信息(通常称作“有效载荷”)本质上等价于——
“Perform an instance method call of M with the following arguments:
“使用下面的参数执行一个称作M的实例方法——
At runtime, assume that the actual type Foo of d1 is not a COM type and does not implement IDynamicObject. In this case the C# runtime binder picks up to finish the overload resolution job based on runtime type information, proceeding as follows:
在运行时,假设d1的实际类型Foo不是COM类型,也没有实现IDynamicObject。在这种情况下,C#运行时绑定器担负起了重载解析的工作,这是基于运行时类型信息完成的,按照下面的步骤进行处理——
Even if the receiver of a method call is of a static type, overload resolution can still happen at runtime. This can happen if one or more of the arguments have the type dynamic:
即便方法调用的接受者是静态类型的,重载解析依然发生在运行时。当一个或多个实参是dynamic类型时就会出现这种情况——
The C# runtime binder will choose between the statically known overloads of M on Foo, based on the runtime type of d, namely Bar. The result is again of type dynamic.
C#运行时绑定器会基于d的运行时类型——也就是Bar——在Foo上M方法的静态可知(statically known)重载之间进行选择。其结果是dynamc类型。
An important component in the underlying implementation of dynamic lookup is the Dynamic Language Runtime (DLR), which is a new API in .NET 4.0.
动态语言运行时(Dynamic Language Runtime,DLR)是动态查找的底层实现的一个重要组件,也是.NET 4.0中新增的API。
The DLR provides most of the infrastructure behind not only C# dynamic lookup but also the implementation of several dynamic programming languages on .NET, such as IronPython and IronRuby. Through this common infrastructure a high degree of interoperability is ensured, but just as importantly the DLR provides excellent caching mechanisms which serve to greatly enhance the efficiency of runtime dispatch.
DLR不仅为C#动态查找,还为很多其他.NET上的动态语言——如IronPython和IronRuby——的实现提供了底层的基础设施。这一通用基础设施确保了高度的互操作性,更重要的是,DLR提供了卓越的缓存机制,使得运行时分派的效率得到巨大的改善。
To the user of dynamic lookup in C#, the DLR is invisible except for the improved efficiency. However, if you want to implement your own dynamically dispatched objects, the IDynamicObject interface allows you to interoperate with the DLR and plug in your own behavior. This is a rather advanced task, which requires you to understand a good deal more about the inner workings of the DLR. For API writers, however, it can definitely be worth the trouble in order to vastly improve the usability of e.g. a library representing an inherently dynamic domain.
对于使用C#动态查找的用户来说,除了更高的性能之外,根本感觉不到DLR的存在。不过,如果你希望实现自己的动态分派对象,可以使用IDynamicObject接口来与DLR互操作,并向其中插入自己的行为。这是一个非常高级的任务,要求对DLR的内部工作原理有相当深入的了解。对于编写API的人,值得在这些问题上花些功夫,这样能够更广泛地改善可用性,例如为一个本身就是动态的领域编写类库。
There are a few limitations and things that might work differently than you would expect.
这里可能有一些限制或与你期望的结果不同。
One consequence of these limitations is that you cannot easily use LINQ queries over dynamic objects:
这些限制导致的结果就是很难在动态对象上使用LINQ查询——
If the Select method is an extension method, dynamic lookup will not find it. Even if it is an instance method, the above does not compile, because a lambda expression cannot be passed as an argument to a dynamic operation.
如果Selected方法是个扩展方法,动态查找将找不到它。即便它是一个实例方法,上面的代码也无法编译,因为lambda表达式不能作为参数传递给动态操作。
There are no plans to address these limitations in C# 4.0.
在C# 4.0中没有计划解决这些限制。
Named and optional parameters are really two distinct features, but are often useful together. Optional parameters allow you to omit arguments to member invocations, whereas named arguments is a way to provide an argument using the name of the corresponding parameter instead of relying on its position in the parameter list.
命名参数和可选参数是两个截然不同的功能,但通常一起使用。在进行成员调用时,可以忽略可选参数;而命名参数的方式可以通过名称来提供一个参数,而无需依赖它在参数列表中出现的位置。
Some APIs, most notably COM interfaces such as the Office automation APIs, are written specifically with named and optional parameters in mind. Up until now it has been very painful to call into these APIs from C#, with sometimes as many as thirty arguments having to be explicitly passed, most of which have reasonable default values and could be omitted.
有些API——尤其是COM接口——如Office自动化API——确实本身就是通过命名参数和可选参数编写的。之前在C#中调用这些API非常痛苦,尤其有的时候需要多达30几个参数都必须显式传递,而其中大多数都具有合理的默认值,是可以忽略的。
Even in APIs for .NET however you sometimes find yourself compelled to write many overloads of a method with different combinations of parameters, in order to provide maximum usability to the callers. Optional parameters are a useful alternative for these situations.
即便是编写.NET中的API,你也会发现很多时候你在被迫为不同的参数组合方式编写一个方法的大量重载形式,以便给调用者提供最高的可用性。在这种情况下,可选参数就会成为一种非常有用的替代方式。
A parameter is declared optional simply by providing a default value for it:
为一个参数提供默认值就可以将其声明为可选的——
Here y and z are optional parameters and can be omitted in calls:
这里的y和z就是可选参数,在调用时可以忽略——
C# 4.0 does not permit you to omit arguments between commas as in M(1,,3). This could lead to highly unreadable comma-counting code. Instead any argument can be passed by name. Thus if you want to omit only y from a call of M you can write:
C# 4.0不允许忽略逗号之间的实参,比如M(1,,3)。否则会导致大量不可读的、需要“数逗号”的代码。替代方式是任何参数都可以通过名字传递。因此如果在调用M时只希望忽略y,可以写——
or
或
or even
甚至
All forms are equivalent, except that arguments are always evaluated in the order they appear, so in the last example the 3 is evaluated before the 1.
这几种形式都是等价的,不过参数总是按照其出现的顺序进行求值,因此对于最后一个示例来说,3会在1之前求值。
Optional and named arguments can be used not only with methods but also with indexers and constructors.
可选参数和命名参数不仅可以用在方法调用中,还可以用在索引器和构造器中。
Named and optional arguments affect overload resolution, but the changes are relatively simple:
命名参数和可选参数影响了重载解析,但产生的变化相当简单——
A signature is applicable if all its parameters are either optional or have exactly one corresponding argument (by name or position) in the call which is convertible to the parameter type.
如果所有的参数或者是可选的,或者在调用时(通过名字或位置)明确提供了对应的实参,并且实参能够转换为形参类型,则该签名是可适用的(applicable)。
Betterness rules on conversions are only applied for arguments that are explicitly given – omitted optional arguments are ignored for betterness purposes.
转换的最优原则只用于明确给定的实参——出于最优的目的,忽略掉的可选参数在重载解析时将不做考虑。
If two signatures are equally good, one that does not omit optional parameters is preferred.
如果两个签名一样好,则没有忽略可选参数的那个胜出。
Given these overloads, we can see the working of the rules above. M(string,int) is not applicable because 5 doesn’t convert to string. M(int,string) is applicable because its second parameter is optional, and so, obviously are M(object) and M(int).
对于给定的这些重载,我们可以看看上述规则的工作方式。M(string,int)不是可适用的,因为5不能转换为string。M(int,string)是可适用的,因为它的第二个参数是可选的,然后很明显,M(object)和M(int)也是可适用的。
M(int,string) and M(int) are both better than M(object) because the conversion from 5 to int is better than the conversion from 5 to object.
M(int,string)和M(int)都比M(object)要好,因为将5转换为int优于将5转换为object。
Finally M(int) is better than M(int,string) because no optional arguments are omitted.
最后,M(int)优于M(int,string),因为它没有被忽略的可选参数。
Thus the method that gets called is M(int).
因此,最终调用的方法是M(int)。
Dynamic lookup as well as named and optional parameters greatly improve the experience of interoperating with COM APIs such as the Office Automation APIs. In order to remove even more of the speed bumps, a couple of small COM-specific features are also added to C# 4.0.
动态查找以及命名参数和可选参数极大地改善了与COM API——如Office Automation API——互操作的体验。为了减少更多的速度损失,C# 4.0还添加了大量特定于COM的小特性。
Many COM methods accept and return variant types, which are represented in the PIAs as object. In the vast majority of cases, a programmer calling these methods already knows the static type of a returned object from context, but explicitly has to perform a cast on the returned value to make use of that knowledge. These casts are so common that they constitute a major nuisance.
很多COM方法接受并返回可变类型,这在PIA中会表现为object。在绝大多数情况下,程序员在调用这些方法之前就已经从上下文中知道了一个返回值对象的静态类型,但为了使用这些知识,必须明确地在返回值上进行类型转换。这些转换非常普遍,带来了巨大的麻烦。
In order to facilitate a smoother experience, you can now choose to import these COM APIs in such a way that variants are instead represented using the type dynamic. In other words, from your point of view, COM signatures now have occurrences of dynamic instead of object in them.
为了得到无缝体验,现在你可以选择使用dynamic类型来代替可变类型的方式。换句话说,从你的角度来看,COM签名中出现的是dynamic而不是object。
This means that you can easily access members directly off a returned object, or you can assign it to a strongly typed local variable without having to cast. To illustrate, you can now say
这意味着你可以直接在返回的对象上访问成员,或者可以使用强类型的局部变量为其赋值,而无需进行转换。例如,你可以写
instead of
而不用写
and
又如
instead of
而不用写
Primary Interop Assemblies are large .NET assemblies generated from COM interfaces to facilitate strongly typed interoperability. They provide great support at design time, where your experience of the interop is as good as if the types where really defined in .NET. However, at runtime these large assemblies can easily bloat your program, and also cause versioning issues because they are distributed independently of your application.
主互操作程序集(Primary Interop Assembly)是从COM接口生成的大型.NET程序集,用于协助完成强类型的互操作。它们为设计时提供了巨大的支持,就好像其中的类型真的是用.NET定义的一样。然而,在运行时这些大型程序集很容易使你的程序膨胀起来,而且很容易导致版本问题,因为它们是分布式的,不依赖你的应用程序。
The no-PIA feature allows you to continue to use PIAs at design time without having them around at runtime. Instead, the C# compiler will bake the small part of the PIA that a program actually uses directly into its assembly. At runtime the PIA does not have to be loaded.
无PIA特性允许你继续在设计时使用PIA,而无需在运行时使用它们。C#编译器会将程序中实际用到的PIA中的一小部分直接编译到程序集中。在运行时无需加载PIA。
Because of a different programming model, many COM APIs contain a lot of reference parameters. Contrary to refs in C#, these are typically not meant to mutate a passed-in argument for the subsequent benefit of the caller, but are simply another way of passing value parameters.
由于采用了不同的编程模型,很多COM API包含大量的引用参数。与C#中的ref相反,这些参数并不意味着要修改传入的实参以供调用方之后使用,而只是另外一种传递参数值的简单方式。
It therefore seems unreasonable that a C# programmer should have to create temporary variables for all such ref parameters and pass these by reference. Instead, specifically for COM methods, the C# compiler will allow you to pass arguments by value to such a method, and will automatically generate temporary variables to hold the passed-in values, subsequently discarding these when the call returns. In this way the caller sees value semantics, and will not experience any side effects, but the called method still gets a reference.
C#程序员必须为所有这些ref参数创建临时变量,并按引用进行传递,这看上去一点也不合理。因此,对于COM方法,C#编译器允许按值传递这些参数,并自动生成存放传入值的临时变量,并在调用返回后丢弃这些变量。使用这种方式,调用方看到的语义是按值传递,而且不会有任何副作用,而被调用的方法得到的依然是一个引用。
A few COM interface features still are not surfaced in C#. Most notably these include indexed properties and default properties. As mentioned above these will be respected if you access COM dynamically, but statically typed C# code will still not recognize them.
一小部分COM接口特性没有出现在C#中。尤其是索引属性和默认属性。如果是动态访问COM,可以用之前提到的特性来解决,但静态类型的C#代码仍然无法识别它们。
There are currently no plans to address these remaining speed bumps in C# 4.0.
在C# 4.0中没有计划解决这些剩余的速度损失。
An aspect of generics that often comes across as surprising is that the following is illegal:
泛型的某个方面会让人感到奇怪,比如下面的代码是不合法的——
The second assignment is disallowed because strings does not have the same element type as objects. There is a perfectly good reason for this. If it were allowed you could write:
第二个赋值是不允许的,因为strings和objects的元素类型并不一样。这样做有这充分的原因。如果允许那样写的话,你可能会写——
Allowing an int to be inserted into a list of strings and subsequently extracted as a string. This would be a breach of type safety.
这会允许将int插入strings列表中,然后将其作为string取出。这会破坏类型安全。
However, there are certain interfaces where the above cannot occur, notably where there is no way to insert an object into the collection. Such an interface is IEnumerable
然而,对于某些接口来说上述情况并不会发生,尤其是不能将对象插入集合时。例如IEnumerable
There is no way we can put the wrong kind of thing into strings through objects, because objects doesn’t have a method that takes an element in. Variance is about allowing assignments such as this in cases where it is safe. The result is that a lot of situations that were previously surprising now just work.
这样就没法通过objects将错误类型的东西插入到strings中了,因为objects没有插入元素的方法。变性(variance)就是用于在这种能保证安全的情况下进行赋值的。结果就是很多之前让我们感到奇怪的情况现在可以工作了。
In .NET 4.0 the IEnumerable
在.NET 4.0中,IEnumerable
The “out” in these declarations signifies that the T can only occur in output position in the interface – the compiler will complain otherwise. In return for this restriction, the interface becomes “covariant” in T, which means that an IEnumerable is considered an IEnumerable if A has a reference conversion to B.
这些声明中的“out”指出T只能出现在接口的输出位置——如果不是这样的话,编译器会报错。有了这一限制,接口对于T类型就是“协变的”,这意味着如果A可以按引用转换为B,则IEnumerable可以当作IEnumerable使用。
As a result, any sequence of strings is also e.g. a sequence of objects.
其结果是,任何一个字符串序列也就是一个对象序列了。
This is useful e.g. in many LINQ methods. Using the declarations above:
这很有用,例如在LINQ方法中。使用上面的定义——
This would previously have been disallowed, and you would have had to to some cumbersome wrapping to get the two sequences to have the same element type.
之前这样做是不允许的,你必须做一些麻烦的包装,使得两个序列具有相同的元素类型。
Type parameters can also have an “in” modifier, restricting them to occur only in input positions. An example is IComparer
类型参数还可以具有“in”修饰符,限制它们只能出现在输入位置上。例如IComparer
The somewhat baffling result is that an IComparer can in fact be considered an IComparer
其结果有点让人迷惑,就是IComparer可以作为IComparer
A generic type can have both in and out modifiers on its type parameters, as is the case with the Func<...> delegate types:
泛型类型可以同时拥有带有in和out修饰符的类型参数,例如Func<...>委托类型——
Obviously the argument only ever comes in, and the result only ever comes out. Therefore a Func can in fact be used as a Func
很明显参数永远都是传入的,而结果永远只能是传出的。因此,Func可以用作Func
Variant type parameters can only be declared on interfaces and delegate types, due to a restriction in the CLR. Variance only applies when there is a reference conversion between the type arguments. For instance, an IEnumerable
变性类型参数只能在接口和委托类型中声明,这是CLR的限制。变性只能应用在类型参数的按引用转换之间。例如,IEnumerable
Also please note that the CTP does not contain the new versions of the .NET types mentioned above. In order to experiment with variance you have to declare your own variant interfaces and delegate types.
还要注意的是,CTP中并没有包含前面提到的.NET类型的新版本。为了试验变性,你需要自己声明变性接口和委托类型。
Here is a larger Office automation example that shows many of the new C# features in action.
这里有一个稍大一些的Office自动化示例,展示了大部分C#新特性的实际应用。
The code is much more terse and readable than the C# 3.0 counterpart.
比起C# 3.0编写的等价代码,这段代码更加简洁可读。
Note especially how the Value property is accessed dynamically. This is actually an indexed property, i.e. a property that takes an argument; something which C# does not understand. However the argument is optional. Since the access is dynamic, it goes through the runtime COM binder which knows to substitute the default value and call the indexed property. Thus, dynamic COM allows you to avoid accesses to the puzzling Value2 property of Excel ranges.
尤其注意如何动态地访问Value属性的。这实际上是一个索引属性,也就是说,这是一个带有参数的属性;C#并不能理解这种属性。然而其参数是可选的。由于访问是动态进行的,运行时COM绑定器会知道用默认值替换参数并调用索引属性。因此,动态COM可以避免访问Excel区域的令人迷惑的Value2属性。
A number of the features introduced to C# 4.0 already exist or will be introduced in some form or other in Visual Basic:
C# 4.0中引入的大量特性已经或者将要以另外的形式引入Visual Basic中——
VB in turn is adding a number of features that have hitherto been a mainstay of C#. As a result future versions of C# and VB will have much better feature parity, for the benefit of everyone.
VB也增加了大量曾经是C#所独有的特性。C#和VB未来的版本在功能上将更加等价,这对于每个人都是有益的。
All available resources concerning C# 4.0 can be accessed through the C# Dev Center at www.csharp.net. Specifically, this white paper and other resources can be found at the Code Gallery site code.msdn.com/csharpfuture. Enjoy!
有关C# 4.0的所有可用的资源都可以在C# Dev Center找到(www.csharp.net)。该白皮书和其他资源可以在Code Gallery站点找到(code.msdn.com/csharpfuture)。祝愉快!