C# 9 引入的 record 与 G# 的 data class 看起来相似，但设计理念和工程体验上有显著差异。

// C#: record —— 语法依赖版本，语义有选择成本
public record Person(string Name, int Age); // C# 9
public record class Person(string Name, int Age); // C# 10 显式
public record struct Point(int X, int Y); // C# 10 value type

// with 表达式
var p2 = p1 with { Age = 31 };

// 解构需要手动声明位置属性，或者使用扩展解构
// G#: data class / data struct —— 从一开始就统一设计
data class Person(name string, age int32) // 引用类型
data struct Point(x int32, y int32) // 值类型 + 自动相等性

// 统一的 with、解构、copy 语义
let p2 = p1 with { age = 31 }
let (name, age) = p1
关键差异有三点。

其一，类型选择意图清晰。 G# 用 data class 和 data struct 明确区分引用语义和值语义；C# 的 record 默认为 record class，record struct 是 C# 10 才补充的，开发者容易混淆默认行为。

其二，封闭性设计。 G# 的 data class 默认是不可继承的（类似于 C# 的 sealed），这符合数据类的使用场景——你很少真的需要继承一个纯粹的数据载体。C# 的 record 默认可继承，带来了额外的复杂性。

其三，data struct 填补了 C# 的一个空白。 C# 的 struct 不提供自动相等性实现，开发者仍需手写 Equals 和 GetHashCode。G# 的 data struct 让值类型也能享受完整的数据类待遇——结构相等性、with 表达式、解构，一样不少。

3.3 可空类型：从 C# 的渐进式到 G# 的原生式
3.3.1 C# nullable reference types 的"半吊子"困境
C# 8.0 引入的可空引用类型（Nullable Reference Types）本意是好的——让编译器帮你捕获潜在的 NullReferenceException。但它在工程实践中遇到了一个根本性的矛盾：它是 opt-in 的。

你需要在 csproj 文件中显式启用：

enable 这个设计决策的后果是深远的。旧代码库默认不启用，空引用异常依然是生产环境的常客。混合代码（可空感知与非可空感知互操作）产生大量难以处理的警告。库作者被迫维护两套 API 签名的心智模型。正如 endjin.com 的技术分析所指出的，可空类型" fortunately "是渐进式采纳的——但如果它们不是默认关闭的，"大多数开发者可能会选择退出 C# 8.0"。这句话本身就是一个设计困境的自白[5]。

更深层的矛盾在于语义不一致。值类型用 Nullable（语法糖为 T?），引用类型用 T? 标注可空——同样是问号，背后的机制完全不同。null 既是关键字、也是值、也是类型修饰符，三重身份让它在代码中无处不在却又难以驯服。

3.3.2 G# 的可空系统：T?、nil、if let、guard let
G# 走了另一条路：空安全不是附加功能，是类型系统的基石。

// G#: 引用类型默认不可空，可空需要显式标注
func findUser(id int32) User? { // 返回可空 User
if id < 0 { return nil } // G# 用 nil，不是 null
return User(“Alice”, 30)
}

// 编译器会阻止你直接访问可空值
func bad(user User?) {
Console.WriteLine(user.name) // 编译错误！user 是 User? 不是 User
}
G# 的可空设计有几个核心原则。

默认不可空。 引用类型默认不可为空，你需要显式写 T? 来表达"这个值可能缺失"。这不是一个可以被关闭的编译器开关——它是语言的一部分。

nil 替代 null。 G# 用 nil 作为空值字面量，如果你不小心输入 null，编译器会抛出诊断错误 GS0273 并提示你改正。这个命名上的区分是一个精心设计的心理暗示：nil 是 Swift 和 Go 的选择，它带有一种"值缺失"的含义，而不像 null 那样带有指针空洞的历史包袱。

T? 编译为 CLR 的 Nullable 或 [Nullable] 注解。 G# 在 CLR 互操作层面统一处理可空性——值类型的 T? 编译为 Nullable，引用类型的 T? 通过 [Nullable] 属性注解。从 C# 代码中调用 G# 库时，可空签名被正确保留；反之亦然。

// if let: 条件解包——Swift 风格的优雅
func greet(name string?) {
if let n = name {
Console.WriteLine(“hi $n”) // n 是 string（非可空）
} else {
Console.WriteLine(“hi stranger”)
}
}

// guard let: 提前返回模式
func length(s string?) int32 {
guard let v = s else {
return -1 // else 分支必须无条件退出
}
return v.Length // v 是 string（非可空）
}
if let 和 guard let 的可贵之处在于它们将空检查与值绑定合二为一。在 if let n = name 的 then 分支中，n 的类型已经被收窄为不可空的 string——不是编译器"假装"知道，而是类型系统的正式收窄。guard let 则服务于防御性编程：它要求 else 分支必须无条件退出（return、throw、break 或 continue），绑定后的值在剩余代码块中自动变为非可空类型。

这套机制的完整图景还包括 ??（null 合并）、?.（空条件访问）、!!（非空断言）和 ??=（复合赋值）。G# 从 Swift 和 Kotlin 那里继承了一整套经过验证的可空处理工具箱，然后将其无缝嵌入 .NET 的类型生态中。

而这一切都发生在编译期。不是运行时的反射检查，不是 IDE 的分析器警告——是类型系统本身的硬约束。这意味着当你的 G# 代码通过编译，空引用异常这类 bug 已经被消灭在萌芽状态。

在下一章中，我们将深入探索 G# 的可空类型系统在实际代码中的运用模式——从 if let 的嵌套技巧到与 C# 遗留代码互操作时的边界处理，你会看到原生空安全如何在工程实践中转化为真正的开发效率。

4. 空值安全：Swift/Kotlin 式的 if let 革命
   “十亿美元的错误”——Tony Hoare 这样形容他在 1965 年引入的 null 引用。六十年后，现代语言终于学会了与空值和平共处。

如果说 G# 的类型系统是一栋精心设计的建筑，那么空值安全就是它的消防系统：平时看不见，关键时刻能救命。第三章我们已经见识了 T? 和 nil 的基本面，这一章要深入的是 G# 空值处理的王牌特性——if let 和 guard let。这两把从 Swift "借来"的利器，让可空值的解包变得前所未有的优雅。

4.1 if let：优雅地处理可空值
4.1.1 一次绑定，双重使命
想象这样一个日常场景：你从配置字典中读取一个用户名，然后决定如何打招呼。C# 的写法是什么样的？

// C#：传统 null 检查，需要显式比较和重新赋值
void Greet(string? maybeName)
{
if (maybeName != null)
{
// maybeName 在这里仍然是 string?，编译器聪明时会收窄
Console.WriteLine($“Hello, {maybeName}!”);
}
else
{
Console.WriteLine(“Hello, stranger!”);
}
}
看起来还行？但这只是最简单的情况。一旦涉及多次解包、链式访问，C# 的嵌套就会迅速膨胀。G# 给出了另一种思路：

// G#：if let 同时完成"非空检查"和"值绑定"
func greet(maybeName string?) {
if let name = maybeName {
// name 在此作用域内类型为 string（非可空）
Console.WriteLine(“Hello, $name!”)
} else {
Console.WriteLine(“Hello, stranger!”)
}
}
if let name = maybeName 这一行做了两件事：首先检查 maybeName 是否为 nil，如果是非空值，则将其绑定到新变量 name 上。name 的类型不再是 string?，而是干净的 string。一次语法动作，完成了逻辑判断和类型收窄，没有冗余的 null 比较，没有额外的变量声明。

4.1.2 类型收窄：编译器替你把关
这就是 if let 的精妙之处——类型收窄（type narrowing）。进入 if let 的 then-branch 后，编译器自动将 T? 收窄为 T。这不是运行时转换，而是编译期的静态保证。你不可能在 if let 块内意外访问到一个 nil 值，因为编译器根本不允许。

G# 还支持多绑定 if let，一次性解包多个可空值：

// G#：多绑定——所有值都非空时才进入 then 分支
func pair(left string?, right string?) {
if let a = left, let b = right {
Console.WriteLine(“$a + $b”) // a 和 b 都是 string
} else {
Console.WriteLine(“Missing at least one value”)
}
}
多绑定的语义是"短路的"：如果 left 为 nil，编译器不会再去检查 right，直接走 else 分支。这种写法在处理多个依赖条件时特别实用——代码扁平、意图清晰，没有"箭头代码"的噩梦。

4.1.3 C# 模式匹配：力拔山兮气盖世
C# 也不是没有解包可空值的手段。C# 8 之后的模式匹配提供了一种替代方案：

// C#：模式匹配 is { } 语法——能工作，但不够自然
void Greet(string? maybeName)
{
if (maybeName is { } name)
{
Console.WriteLine($“Hello, {name}!”);
}
else
{
Console.WriteLine(“Hello, stranger!”);
}
}
maybeName is { } name 这行代码的工作原理是：先用属性模式 { } 检查值非空，同时将结果绑定到 name 变量。它确实能实现类似的效果，但让我们诚实一点——is { } 是什么？一个空属性模式？这更像是模式匹配系统的"副作用"被借来做空值检查，而不是为此场景专门设计的语法。

对比 if let name = maybeName 和 if (maybeName is { } name)，前者像是一句自然的英语，后者像是一道谜语。好的语法应该让意图一目了然，而不是让读者停下来解码模式匹配的规则。

4.2 guard let：提前返回的哲学
if let 解决了"条件解包"的问题，但还有一种更常见的模式：函数开头验证输入，如果不合法就立刻返回。Swift 发明了 guard let 来应对这个场景，G# 原样采纳。

// G#：guard let —— “守卫"住必要条件
func process(user User?) {
guard let u = user else {
Console.WriteLine(“No user provided”)
return
}
// u 在这里已经是 User 类型（非可空）
Console.WriteLine(u.name)
Console.WriteLine(u.email)
// 后续所有代码都可以安全使用 u
}
guard let 的语义非常严格：它要求 else 分支必须无条件退出当前作用域——return、throw、break 或 continue 都可以，但不能"继续往下走”。一旦通过了 guard let 的"关卡"，后续代码就可以放心使用绑定变量，无需再担心空值问题。

这种"提前返回"（early return）的哲学，让代码的主路径保持扁平。对比一下不用 guard let 的写法：

// 没有 guard let：主逻辑被迫嵌套在 if 块里
func process(user User?) {
if let u = user {
Console.WriteLine(u.name)
Console.WriteLine(u.email)
} else {
Console.WriteLine(“No user provided”)
}
}
在这个简单例子里差异不大，但当函数有多个前置条件时——用户非空、用户已激活、用户有权限——guard let 的优势就凸显出来了。三个 guard let 依次排列，每个不通过就提前退出，主逻辑干干净净地躺在函数底部，不被层层嵌套掩埋。

4.3 空值操作符全家桶
if let 和 guard let 处理的是"需要分支判断"的场景，但日常编程中还有大量"一行搞定"的空值操作需求。G# 提供了一整套与 C# 兼容、同时借鉴 Swift/Kotlin 的操作符。

4.3.1 ??、??=、?.、!! 的协同
// G#：空值操作符的完整演示
func demo(config map[string, string]) {
// ?. —— 空条件访问（链式调用中的安全网）
var user = findUser(“Alice”)
var display = user?.name?.uppercased() ?? “UNKNOWN”

// ?? —— Elvis 运算符，提供默认值
var port = config["port"] ?? "8080"

// ??= —— 仅在 nil 时赋值，懒初始化的利器
var cache map[string, int32]?
cache ??= make(map[string, int32])  // 仅在 cache 为 nil 时创建
cache ??= make(map[string, int32])  // 第二次，cache 已非 nil，忽略

// !! —— 非空断言："我确信这里不是 nil，如果不是请崩溃"
var forced = findUser("Bob")!!
Console.WriteLine(forced.name)  // 如果 findUser 返回 nil，立即抛异常

}
四个操作符分工明确：?. 负责安全导航，?? 提供退路，??= 处理懒初始化，!! 则是开发者的"军令状"——我担保这个值非空，如果不是我的错。值得注意的是，G# 的非空断言是 !! 双感叹号，而 C# 是单 !。这是有意为之：! 在 C# 中更像是"抑制编译器警告"的提示，而 G# 的 !! 更接近 Kotlin 的语义——运行时真的会检查，失败会抛异常，不是简单地消音警告。

4.3.2 四语言空值处理对照表
操作 C# G# Swift Kotlin
可空类型声明 string? string? String? String?
空值字面量 null nil nil null
条件解包 if (x is { } v) if let v = x if let v = x x?.let { }
提前返回 手动检查 guard let v = x guard let v = x x ?: return
空合并（Elvis） ?? ?? ?? ?:
空合并赋值 ??= ??= — —
空条件访问 ?. ?. ?. ?.
非空断言 !（消音警告） !!（运行时检查） ! !!
这张表格揭示了一个有趣的语言演化脉络。空条件访问 ?. 已经是四语言的共识——这个运算符太好用了，没有人想发明替代品。空合并方面，C# 和 G# 的 ?? 与 Kotlin 的 ?: 只是符号差异，语义完全一致。但条件解包是分歧最大的地方：Swift 和 G# 的 if let 最为自然，Kotlin 的 ?.let 稍显间接（它实际上是在可空值上调用方法），而 C# 的 is { } v 则是模式匹配的"旁门左道"。

G# 的选择很聪明：它没有在每一站都重新发明轮子，而是挑选了各个语言中被证明最优雅的方案——Swift 的 if let/guard let、C# 的 ??/?.、Kotlin 的 !!，然后将它们编织成一个连贯的空值处理体系。对从 C# 迁移过来的开发者来说，?? 和 ?. 是熟悉的老朋友；而从 Swift 或 Kotlin 过来的开发者，则会惊喜地发现 if let 在这里同样可用。这种"兼容并包"的设计哲学，让 G# 的空值安全既有 C# 的亲切感，又有现代语言的优雅度——而这，恰恰是 G# 这门语言整体气质的一个缩影。

5. 结构化并发：scope、async 与 goroutine
   并发编程是现代软件开发的核心技能，也是最容易出错的地方之一。一个异步任务在后台默默崩溃、一个 goroutine 泄漏导致内存暴涨、一个 fire and forget 操作让异常石沉大海——这些场景每天都在世界各地的代码库中重演。G# 对这个问题给出了一个独特的答案：不是选择一种并发模型，而是将三种经过验证的模型精心整合到一个统一的下层之上[1]。

5.1 scope：并发的生命周期管理
C# 开发者对 async/await 的传染性都不陌生。一旦某个方法变成异步，调用链上的每一层都不得不跟着变——GetDataAsync 强迫 ProcessAsync 变成 async，ProcessAsync 又强迫 HandleAsync 跟着变，一直传染到 Main[2]。这种"传染链"不仅增加了样板代码，更隐藏了一个更深的问题：异步任务的生命周期管理缺乏结构化保障。

在 C# 中，如果你想确保一组并发任务全部完成后再继续执行，通常需要这样写：

// C#: 手动管理任务生命周期
static async Task FetchAllAsync(CancellationToken ct)
{
var task1 = FetchUserAsync(1, ct);
var task2 = FetchUserAsync(2, ct);

// 必须显式等待全部完成
await Task.WhenAll(task1, task2);

var user1 = await task1;  // 解包结果
var user2 = await task2;
Console.WriteLine($"Got {user1.Name} and {user2.Name}");

}
这段代码有两个隐患：一是忘记调用 Task.WhenAll 会导致任务在后台静默运行，二是 CancellationToken 需要手动传递到每一个调用点。G# 的 scope 块借鉴了 Kotlin 的结构化并发理念，将任务的生命周期与代码块的作用域绑定在一起[1]：

// G#: scope 自动管理子任务生命周期
import System.Threading.Tasks

func fetchAll() async {
scope {
let task1 = fetchUser(1)
let task2 = fetchUser(2)
let user1 = await task1
let user2 = await task2
Console.WriteLine(“Got $user1.Name and $user2.Name”)
} // 块结束时自动等待所有子任务
}
scope { … } 的核心语义很简单：当代码执行离开这个块时，编译器确保块内启动的所有异步操作都已经完成[3]。如果有任何子任务抛出异常，异常会被聚合并传播到 scope 的退出点——子工作不会静默丢失。这意味着你不再需要手动调用 Task.WhenAll，也不需要把 CancellationToken 当作"传染病"一样到处传递。

5.2 async/await：与 Task[T] 的无缝融合
G# 的 async func 在语法层面做了大量简化，但在编译层面，它完全拥抱了 .NET 成熟的异步基础设施。ADR-0023 明确规定：G# 的 async 状态机发射采用标准 .NET 实现[4]。这意味着什么？

// G#: async func 自动推断返回类型
async func compute(n int32) int32 {
await Task.Delay(5)
return n * 2 // 编译为 Task[int32]
}

// G#: void 返回编译为 Task
async func logDelay(message string) {
await Task.Delay(10)
Console.WriteLine(message) // 编译为 Task
}
对比 C# 的写法，差异一目了然：

// C#: 必须显式声明 Task 返回类型
static async Task ComputeAsync(int n)
{
await Task.Delay(5);
return n * 2;
}

static async Task LogDelayAsync(string message)
{
await Task.Delay(10);
Console.WriteLine(message);
}
G# 编译器自动推断 async func 的返回类型——有值返回的是 Task[T]，无值返回的是 Task。这种语法糖不仅仅是少写几个字符的问题，它反映了一种设计哲学：让编译器承担类型声明的机械工作，让开发者专注于业务逻辑。

更重要的是，G# 的 Task[T] 与 C# 的 Task 是同一个 CLR 类型。你可以在 G# 代码中调用 C# 的异步方法，C# 代码也可以无缝调用 G# 的 async func——没有互操作层，没有包装器，没有性能损失。

async sequence[T]：异步流处理
当需要处理异步数据流时，G# 提供了 async sequence[T]，编译后对应 C# 的 IAsyncEnumerable[5]。

// G#: 异步序列生成器
async func ticks() async sequence[int32] {
var i = 0
while i < 5 {
await Task.Delay(10)
yield i // 产生异步流元素
i++
}
}

// 消费异步序列
func main() {
scope {
await for v in ticks() {
Console.WriteLine(“tick: $v”)
}
}
}
C# 对应的写法使用 yield return 和 await foreach：

// C#: IAsyncEnumerable 生成与消费
static async IAsyncEnumerable TicksAsync()
{
int i = 0;
while (i < 5)
{
await Task.Delay(10);
yield return i++;
}
}

static async Task ConsumeAsync()
{
await foreach (var v in TicksAsync())
{
Console.WriteLine($“tick: {v}”);
}
}