C# 8.0 预览特性

初试C# 8.0

Visual Studio 2019的第一个预览版（使用Visual Studio 2019提高每个开发人员的工作效率）和.NET Core 3.0（宣布.NET Core 3预览1和开源Windows桌面框架）。

其中一个令人兴奋的方面是你可以使用C＃8.0中的一些功能！在这里，我将带您进行一次导游，了解您可以在预览中尝试的三种新的C＃功能。并非所有C＃8.0功能都可用。如果您想了解所有主要功能，请阅读最近发布Building C# 8.0，或查看Channel 9或YouTube。

做好准备

首先，下载并安装.NET Core 3.0的预览版1和Visual Studio的2019的预览版1。在Visual Studio中，确保选择工作负载“.NET Core跨平台开发”（如果您忘记了，可以稍后通过打开Visual Studio安装程序并单击Visual Studio 2019预览频道上的“修改”来添加它）。

启动Visual Studio 2019预览版，创建新项目，然后选择“Console App（.NET Core）”作为项目类型。

项目启动并运行后，将其目标框架更改为.NET Core 3.0（在解决方案资源管理器中右键单击该项目，选择“属性”并使用“应用程序”选项卡上的下拉菜单）。然后选择C＃8.0作为语言版本（在项目页面的Build选项卡上单击“Advanced ...”并选择“C＃8.0（beta）”）。

现在，您可以轻松获得所有语言功能和支持框架类型！

可空的引用类型

可空引用类型功能旨在警告您代码中的null不安全行为。既然我们之前没有这样做过，那么现在就开始改变吧！为避免这种情况，您需要选择加入该功能。

不过，在我们开启它之前，让我们写一些非常糟糕的代码：

using static System.Console;

class Program
{
    static void Main(string[] args)
    {
        string s = null;
        WriteLine($"The first letter of {s} is {s[0]}");
    }
}

如果你运行它，你当然会得到一个空引用异常。你陷入了黑洞！你怎么知道不要在特定的地方间接引用s？嗯，因为在前一行分配了null。但是在现实生活中，它可能不是在前一行，而是在你编写代码的三年后在地球另一端运行的其他人程序集中。你怎么知道不写那个？这是可空引用类型要回答的问题！所以让我们打开它们吧！

对于一个新项目，你应该立即打开它们。事实上，我认为它们应该在新项目中默认启用，但我们在预览中没有这样做。打开它们的方法是将以下行添加到.csproj文件中，例如在切换到上面的C＃8.0时刚刚插入的LanguageVersion之后：

<NullableReferenceTypes>true</NullableReferenceTypes>

保存.csproj文件并返回到您的程序：发生了什么？你有两个警告！每个代表一个功能的“一半”。让我们依次看看它们。第一个是null这一行：

string s = null;

它抱怨你将null赋给“不可空类型”：啥？！？当打开该功能时，在普通的引用类型中不再欢迎使用null，例如string！因为，你知道吗，null不是一个字符串！我们一直假装在过去的五十年在面向对象编程，但实际上null并不是一个对象：这就是为什么每当你试图将它做为对象时一切都会爆炸！

所以不多说：null是禁止的，除非你要求它。你是怎么要求的？通过使用可空的引用类型，例如string?。尾随问号表示允许null：

string? s = null;

警告消失了：我们已明确表达了此变量保持null的意图，所以现在没问题了。

直到下一行代码！在该行:

WriteLine($"The first letter of {s} is {s[0]}");

它抱怨s中s[0]，你可能会间接引用一空引用。果然：是！干得好，编译器！你怎么解决它？嗯，这几乎取决于你 - 无论何种方式你得修复它！让我们尝试初学者的方法, 只在s非null时执行该行：

if (s != null) WriteLine($"The first letter of {s} is {s[0]}");

警告消失了！为什么？因为编译器可以看到，只有s不是null时才会走后面的代码。它实际上进行了全流分析，跟踪每行代码中的每个变量，以便密切关注它可能是null的和可能不是的位置。它会监视您的测试和作业，并进行簿记(bookkeeping)。

我们试试另一种方法：

WriteLine($"The first letter of {s} is {s?[0] ?? '?'}");

这使用null条件索引运算符s?[0]，它避免了间接引用，如果s为null ，则生成null。现在我们有一个可空的char?，但是null合并运算符?? '?'替换null值为字符 '?'。因此避免了所有null间接引用。编译器很高兴，没有给出警告。

正如您所看到的，该功能可以让您在编写代码时保持诚实：它会强制您在系统中使用null时通过使用可空的引用类型来表达您的意图。并且一旦出现null，它就会强制您负责任地处理它，让您在存在可能间接引用null值以触发空引用异常的风险时进行检查。

你现在完全null安全了吗？没有。有几种方法可以使null值漏掉并导致空引用异常：

• 如果你调用没有可空的引用类型功能的代码（也许它是在该功能存在之前编译的），那么我们无法知道该代码的意图是什么：它没有区分可空和不可空 - 我们说它是“无视的”。所以我们给它一个通行证; 我们根本不会对此类调用发出警告。
• 分析器本身有一些漏洞。其中大多数是安全和便利之间的权衡; 如果我们抱怨，那将很难修复。例如，当你编写时new string[10]，我们创建一个充满null值的数组，类型为非null字符串。我们不会对此发出警告，因为编译器如何跟踪您初始化所有数组元素？

但总的来说，如果你广泛使用这个功能（即在任何地方打开它），它应该照顾绝大多数的空引用。

毫无疑问地,我们打算在现有代码上开始使用该功能！一旦打开它，您可能会收到很多警告。其中一些实际上代表了问题：是的，你发现了一个错误！其中一些可能有点烦人; 你的代码显然是null安全的，你只是没有工具来表达你的意图：你没有可空的引用类型！例如，在我们开始的行：

string s = null;

这在现有代码中将非常普遍！正如你所看到的那样，我们也确实在下一行发出了警告，我们试图间接引用它。因此，从安全的角度来看，此处的赋值警告严格来说是多余的：它使您在新代码中保持诚实，但修复现有代码中的所有事件并不会使其更安全。对于这种情况，我们正在处理一种模式，其中某些警告被关闭，当它不影响空安全性时，因此升级现有代码不那么令人生畏。

另一个有助于升级的功能是，您可以使用编译器指令#nullable enable和#nullable disable在代码中“本地”打开或关闭该功能。这样你就可以逐步完成你的项目并逐步处理注释和警告。

要了解更多关于可空引用类型检查出Overview of Nullable types和Introduction to nullable tutorial。

为了更深入的设计理由，去年我在C＃中写了一篇帖子Introducing Nullable Reference Types in C#。

如果您想让自己沉浸在设计工作的日常工作中，请查看GitHub上的Language Design Notes，或者Nullable Reference Types Specification。

范围和索引

使用索引数据结构时，C＃的表现力越来越强。曾经想要简单的语法来切出数组，字符串或span的一部分吗？现在你可以！

继续将您的程序更改为以下内容：

using System.Collections.Generic;
using static System.Console;

class Program
{
    static void Main(string[] args)
    {
        foreach (var name in GetNames())
        {
            WriteLine(name);
        }
    }

    static IEnumerable<string> GetNames()
    {
        string[] names =
        {
            "Archimedes", "Pythagoras", "Euclid", "Socrates", "Plato"
        };
        foreach (var name in names)
        {
            yield return name;
        }
    }
}

让我们来看看迭代名字数组的那段代码。修改foreach如下：

foreach (var name in names[1..4])

看起来我们正在迭代名字1到4。事实上代码运行时也确实如此！终点是排外的，即不包括元素4。1..4实际上是一个范围表达式，它不必像该处一样，作为索引操作的一部分出现。它有一种自己的类型，叫做Range。如果我们想要的话，我们可以把它拉到自己的变量中，它会起到同样的作用：

Range range = 1..4;
foreach (var name in names[range])

范围表达式的终点不必是整数。事实上，它们属于一种类型,叫Index，可由非负数转换得来。但是你也可以使用一个新的^运算符创建Index，意思是“从末尾”。所以^1是从末尾开始1个：

foreach (var name in names[1..^1])

这会在数组的每一端去除一个元素，产生一个带有中间三个元素的数组。

范围表达式可以在任一端或两端打开。..^1与0..^1相同。1..与1..^0相同。并且..与0..^0相同：从头到尾。试试吧！尝试在Range的两端混合使用“从开始”和“从末尾”的Index,看看会发生什么。

范围不仅仅适用于索引器。例如，我们计划有重载string.SubString，SPan<T>.Slice以及使用Range参数的AsSpan扩展方法。这些不在.NET Core 3.0预览中。

异步流

IEnumerable<T>在C＃中扮演着特殊的角色。“IEnumerables”代表各种不同的数据序列，并且语言具有用于消费和生成它们的特殊构造。

正如我们在当前的程序中看到的那样，它们通过foreach声明来消费，该声明涉及获取枚举器的苦差事，反复推进它，沿途提取元素，最后处理枚举器。并且可以使用迭代器生成它们：yield return按消费者要求产生元素。但两者都是同步的：当结果被请求时最好已经准备就绪,否则就会阻塞线程！

async和await加入到C＃中用来处理当结果被请求时不一定准备好的情况。它们可以异步await，并且线程可以在其可用之前执行其他操作。但这仅适用于单个值，而不适用于随时间逐渐和异步生成的序列，例如来自IoT传感器的测量值或来自服务的流数据。

异步流在C＃中将异步和枚举结合在一起！让我们看看，通过逐步“异步”我们当前的程序。

首先，让我们在文件的顶部添加另一个using指令：

using System.Threading.Tasks;

现在让我们通过在yield return名字之前增加一个异步延迟来模拟GetNames做了一些异步工作：

await Task.Delay(1000);
yield return name;

当然，我们得到了一个错误: 只能在async方法中使用await。所以我们让它异步：

static async IEnumerable<string> GetNames()

现在我们被告知我们没有为异步方法返回正确的类型，这是公平的。但除了通常的Task东西之外，这次我们的类型列表中有了一个新的候选可以返回：IAsyncEnumerable

static async IAsyncEnumerable<string> GetNames()

就像我们已经生成了一个异步字符串流！根据命名指南，让我们重命名GetNames为GetNamesAsync。

static async IAsyncEnumerable<string> GetNamesAsync()

现在我们在Main方法中的这一行得到一个错误：

foreach (var name in GetNamesAsync())

不知道如何foreach一个IAsyncEnumerable<T>。这是因为异步流的foreach需要显式使用await关键字：

await foreach (var name in GetNamesAsync())

这是foreach的异步版本:采用异步流并等待每个元素！当然它只能在异步方法中这样做，所以我们必须使我们的Main方法异步。幸运的是，C＃7.2增加了对它的支持：

static async Task Main(string[] args)

现在所有的混乱都消失了，程序是正确的。但是如果你尝试编译并运行它，你会得到一些令人尴尬的错误。那是因为我们搞砸了一下，并没有完全对齐.NET Core 3.0和Visual Studio 2019的预览。具体来说，有一种实现类型，异步迭代器利用它与编译器期望的不同。