C# 7.1先睹为快(第二部分)

栏目: ASP.NET · 发布时间: 7年前

内容简介:C# 7.1先睹为快(第二部分)

天我们介绍了异步Main函数(Async Main)和默认表达式(Default Expressions)。我们的C# 7.1之旅将继续,今天要介绍的特性在建议中称为推导元组名(Infer Tuple Names)和使用泛型的模式匹配(Pattern-matching with Generics)。

推导元组名(Infer Tuple Names)

虽然开发人员不常考虑到,但是C#中的匿名类型包括了命名推导。例如,编写如下代码时,对象y将具有名为A和B的属性:

var y = new { x.A, x.B };

根据“推导元组名建议”,值元组基本具有同样的功能。

var z1 = (A: x.A, B: x.B); //显式名字。
var z2 = (x.A, x.B); //推导名字。

但是匿名类型和值元组间存在着一些显著的差异:

  • 匿名类型需要属性名,属性明可以是显示指定的,也可以是推导得到的。
  • 值元组会将未命名属性标为Item1、Item2等。
  • 如果匿名类型具有重复的名字,那么会产生编译错误。
  • 如果值元组具有重复的显式名字,那么会产生编译错误。
  • 如果值元组具有重复的推导名字,那么推导名会被跳过。例如:(x.A, x.B, y.A)将转化成(Item1, B, Item3)。
  • 值元组不能使用如下保留名字:ToString、Rest、ItemN(N是大于0的数字)。

C#和VB间有hen一个有意思的差别,VB可以通过函数去推导匿名属性名。例如:

var y = new { x.A, x.Bar() }; //编译错误
Dim y = New With {x.A, x.Bar()} //匿名类型{A,Bar}

该功能特性将扩展适用于VB元组。

但如果恰巧有一个扩展方法使用了与推导属性一样的名字,这一特性就会引发破坏性更改。在建议中进一步提出:

考虑到这一更改的破坏性有限,并且在C# 7.0中,交付元组的时间窗很短,兼容性委员会认为这种破坏性更改是可以接受的。

考虑泛型约束的元组名

如果存在元组名不匹配的问题,那么编译器会尽量警告编程人员。例如:

public static (int A, int B) Test1((int A, int B) a)
Test1((A: 1, B: 2));
Test1((X: 1, Y: 2)); //给出警告,元组名不匹配。

如果开始采用泛型约束,代码就不工作了:

public static T Test2

 (T a) where T : IEnumerable<(int A, int B)>
Test2(new List<(int A, int B)>());
Test2(new List<(int X, int Y)>()); //没有警告。

当给出前的解释是,在泛型约束的条件下,编译器是不会去检查元组名的。理论上讲,编译器是可以捕获这类问题的,但是所付出的性能上的代价要远高于所得到的收益。

使用泛型的模式匹配

模式匹配是C# 7.0中新提供的特性。但是使用该特性时,存在 设计上的缺陷 。让我们看一下Alex Wiese给出的如下代码:

class Program
{
    static void Main(string[] args) {}
    public void Send

 (T packet) where T : Packet
    {
        if (packet is KeepalivePacket keepalive)
        {
            // 使用keepalive的功能代码。
        }
        switch (packet)
        {
            case KeepalivePacket keepalivePacket:
                // 使用keepalivePacket的功能代码。
                break;
        }
    }
}
public class Packet {}
public class KeepalivePacket : Packet {}

代码会报如下错误:“An expression of type T cannot be handled by a pattern of type KeepalivePacket.”。但如果我们将参数改为System.Object类型,而不是T类型,代码就工作正常了。

public void Send(object packet)

C# 7.1,通过 对引发模式匹配的规则进行微调 ,修正了这一问题。

我们改进了“模式匹配技术规范”中的一段内容,下面以粗体标出了我们所建议添加的内容:

我们认为左侧(left-hand-side)静态类型的特定组合与特定类型是不兼容的,这会导致编译时错误。我们称静态类型E的值与类型T是模式兼容的,如果存在标识转换(Identity Conversion)、隐式引用转换(Reference Conversion)、装箱转换(Boxing Conversion)、显式引用转换,或者存在从E到T的拆箱转换(Unboxing Conversion), 或者E或T均为开放类型(Open Type) 。如果具有类型E的表达式与其所匹配的类型模式中的类型并不模式兼容,就会产生编译时错误。

这被认为是一个软件问题修复问题。由于该更新是“向前不兼容”的,因此只有将编译器设为C# 7.1,才能使用这一更新。

查看英文原文: An Early Look at C# 7.1: Part 2


以上所述就是小编给大家介绍的《C# 7.1先睹为快(第二部分)》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

GWT in Action

GWT in Action

Robert Hanson、Adam Tacy / Manning Publications / 2007-06-05 / USD 49.99

This book will show Java developers how to use the Google Web Toolkit (GWT) to rapidly create rich web-based applications using their existing skills. It will cover the full development cycle, from ......一起来看看 《GWT in Action》 这本书的介绍吧!

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

在线进制转换器
在线进制转换器

各进制数互转换器

SHA 加密
SHA 加密

SHA 加密工具