尧图网站建设 
Roc 语言在 expect 顶层表达式中混用不同类型 Err 的?Try 后缀操作符语义剖析【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc导读本文围绕 Roc 编译器快照测试 question_in_expect_mixed_err_types.md 展开深入讲解一个容易困惑的语言特性在顶层expect表达式中两个携带不同类型 Err如[BadA]与[BadB(Str)]的Try值可以同时使用?操作符而无类型冲突。读完本文你将理解?在expect语境下与普通函数体内使用的根本差异——Err 分支被解包并丢弃unwrapped and discarded而非与返回类型统一并掌握其背后的 Token 切分、AST 形状、规范化canonicalize脱糖细节与可运行的验证方法。expect中的?文档快照的完整源码该快照的SOURCE部分给出了一个最小但完整的 Roc 程序两行类型注解加上两个平凡实现构成整个测试的核心parse_a : Str - Try(I64, [BadA]) parse_a |_s| Ok(1) parse_b : Str - Try(I64, [BadB(Str)]) parse_b |_s| Ok(1) expect parse_a(1)? parse_b(1)?观察点有三parse_a返回Try(I64, [BadA])其中Try是 Roc 内建的双参类型构造器第二参数[BadA]是无载荷的标签联合tag unionparse_b返回Try(I64, [BadB(Str)])其 Err 分支BadB携带一个Str载荷顶层expect的两侧各自通过后缀?解包Try值随后比较解包出的I64。在普通函数体内?的 Err 类型必须与函数的返回类型统一而这里两个?的 Err 类型完全不同编译却完全通过——快照的EXPECTED与PROBLEMS均为NIL表示编译零诊断、零报告。这正是该测试要固化的语义expect不是函数没有返回类型可供 Err 统一于是每个 Err 类型被独立解包并丢弃互不干扰。为什么expect语境下 Err 不需要统一语义前提?文档 token 流中的NoSpaceOpQuestion在 Roc 中语义上等价于若成功则取出 Ok 载荷若失败则提前返回 Err。但提前返回需要一个返回目标在函数体内?的 Err 类型必须与函数声明的返回类型或其子类型兼容否则类型检查失败在顶层expect中不存在任何返回类型。此时编译器的行为退化为成功分支取出 Ok 值继续求值失败分支把 Err解包并丢弃unwrapped and discarded转而将整个expect判定为失败。于是两个不同 Err 类型[BadA]与[BadB(Str)]之间不需要任何统一关系它们各自沿着自己的失败分支走即可。快照 META 中的description精确概括了这一设计since each Err type is unwrapped and discarded rather than unified with a return type。从源码结构看这一语义在规范化阶段体现为一个专门的错误处理表达式——e-expect-err见下节脱糖细节它仅在expect上下文中由 Try 后缀脱糖产生与普通函数中的返回式错误传播在 src/canonicalize 目录中是分开实现的。规范化CANONICALIZE脱糖?如何变成 match expect-err快照的CANONICALIZE部分展示了?在规范化后的真实形态。以parse_a(1)?为例脱糖结果是一个e-match其条件表达式调用parse_a并包含恰好两个分支第一个分支匹配#okp-nominal-external (builtin)表示内建Try的Ok标签命中后取出载荷1e-lookup-local #ok第二个分支匹配#err命中后产生e-expect-err并把原始源码片段parse_a(1)?作为上下文信息(snippet parse_a(1)?)随错误表达式一并记录。parse_b(1)?在右侧以完全相同的结构脱糖只是对应#err的载荷类型是BadB(Str)。整个expect的两侧最终包裹在e-method-eq即比较之下。两个e-match的失败分支各自独立没有任何交叉统一从 IR 层面直接印证了每个 Err 类型被独立解包并丢弃的语义。这一脱糖形态与 src/canonicalize/test/try_suffix_test.zig 中的单元测试相互印证测试通过expectMatch辅助函数断言 Try 后缀脱糖后的表达式为e_match且is_try_suffix标记为真、分支数量恰为 2sliceMatchBranches(match.branches).len 2与快照中两个分支#ok与#err的结构完全一致。由此可以推断Try 后缀在规范化阶段是统一生成Ok/Err 双分支 match的标准脱糖而expect语境下的失败分支被专门路由到e-expect-err而非返回式传播。TOKENS 与 PARSE从词法到语法树的证据快照的TOKENS部分给出了完整的 token 流其中与本主题最相关的是最后一行KwExpect, LowerIdent, NoSpaceOpenRound, StringStart, StringPart, StringEnd, CloseRound, NoSpaceOpQuestion, OpEquals, LowerIdent, NoSpaceOpenRound, StringStart, StringPart, StringEnd, CloseRound, NoSpaceOpQuestion, EndOfFile关键信息?被词法分析为独立的NoSpaceOpQuestiontoken紧跟在实参右括号之后、OpEquals之前共出现两次expect关键字对应KwExpect字符串字面量被拆分为StringStart/StringPart/StringEnd三段。对应的PARSE部分则展示语法树形状顶层由两个s-type-annoStr - Try(I64, [BadA])与Str - Try(I64, [BadB(Str)])、两个s-decllambda 实现|_s| Ok(1)以及一个s-expect组成。在s-expect内部parse_a(1)?被解析为e-question-suffixTry 后缀表达式作为e-binop (op )的左操作数右侧同理。也就是说语法树上?直接挂接在expect的操作数表达式上从解析阶段起就没有任何返回类型的概念介入为后续规范化阶段走e-expect-err路径埋下伏笔。TYPES 与内建类型Try、I64 的推导确认快照末尾的TYPES部分给出类型检查结果(patt (type Str - Try(I64, [BadA]))) (patt (type Str - Try(I64, [BadB(Str)])))两个函数的类型与注解完全一致且规范化 IR 中Try通过(ty-apply (name Try) (builtin) ...)引用、I64/Str通过(ty-lookup ... (builtin))引用确认它们都是 Roc 内建类型。这带来两个直接推论Try作为内建类型构造器其 Ok 分支载荷I64在两侧解包后可直接用比较两侧e-method-eq的载荷类型均为I64BadA与BadB(Str)仅作为标签联合出现在各自函数签名中从不参与跨函数的统一这正是本快照能够零诊断通过的类型学原因。同主题快照串读?在 expect 中的完整行为矩阵该快照并非孤例test/snapshots目录下存在一组专门覆盖?在 expect 中行为的快照可串读以获得完整语义图景question_in_expect_err_type_unbound.md验证顶层expect中?的操作数约束为Try且Err 类型保持未绑定left unbound同样不存在返回式类型推导question_in_expect_no_unused_warning.md回归测试issue 9612确保expect内?脱糖出的 Err 载荷不会产生 UNUSED VARIABLE 警告——因为失败分支的载荷被解包并丢弃本就无意使用question_in_inline_expect.md 与 question_in_lambda_inside_expect.md分别覆盖内联expect与expect内 lambda 中?的等价行为。加上本文主角question_in_expect_mixed_err_types.md这组快照从Err 未绑定无未使用警告混合 Err 类型内联/嵌套位置四个维度把?在 expect 语境下的特殊语义钉死为编译器回归测试任何行为漂移都会在快照比对中现形。快照机制与运行验证本文件属于 test/snapshots 目录下的snippet 型快照。根据 test/snapshots/README.md快照测试通过捕获源代码在每个编译阶段词法、解析、规范化、类型检查等的输出来验证编译器行为并防止回归EXPECTED/PROBLEMS为NIL表示该源码编译产生零报告reporting.Report为空语义诊断快照与渲染输出快照分离管理普通快照typesnippet等只固定诊断语义渲染细节边框字符、ANSI、换行则属于reporting/目录的专用快照。如需在本地复现或更新该快照可运行Zig 构建环境# 生成全部快照 zig build run-snapshot-tool # 仅更新指定快照 zig build run-snapshot-tool -- test/snapshots/question_in_expect_mixed_err_types.md # 将 PROBLEMS 中的实际诊断回写为期望值 zig build run-snapshot-tool -- test/snapshots/question_in_expect_mixed_err_types.md --update-expected注意快照文件本身是只读的期望基准日常开发中不应手工修改只有在编译器行为被有意变更时才通过上述工具重新生成。小结三条可直接引用的结论?的语义是上下文相关的在函数体内它做返回式错误传播Err 与返回类型统一在顶层expect中它做解包并丢弃Err 无需统一两者在规范化阶段走不同路径e-expect-errvs 普通返回。混合 Err 类型合法且无需转换Try(I64, [BadA])与Try(I64, [BadB(Str)])可以在同一个expect中同时用?因为每个失败分支独立解包、独立丢弃载荷差异完全不参与统一。该行为有编译器级回归保护本文分析的快照及其同主题系列、try_suffix_test.zig 单元测试共同构成三重证据链任何偏离都会导致快照比对或单测失败。如果你正在阅读或贡献 Roc 编译器请以 question_in_expect_mixed_err_types.md 为最小复现单元结合 src/canonicalize 中 Try 后缀的脱糖实现和 try_suffix_test.zig 的断言来验证你对?语义的全部理解。【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Roc 语言在 expect 顶层表达式中混用不同类型 Err 的 `?`（Try 后缀）操作符语义剖析
Roc 语言在 expect 顶层表达式中混用不同类型 Err 的?Try 后缀操作符语义剖析【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc导读本文围绕 Roc 编译器快照测试 question_in_expect_mixed_err_types.md 展开深入讲解一个容易困惑的语言特性在顶层expect表达式中两个携带不同类型 Err如[BadA]与[BadB(Str)]的Try值可以同时使用?操作符而无类型冲突。读完本文你将理解?在expect语境下与普通函数体内使用的根本差异——Err 分支被解包并丢弃unwrapped and discarded而非与返回类型统一并掌握其背后的 Token 切分、AST 形状、规范化canonicalize脱糖细节与可运行的验证方法。expect中的?文档快照的完整源码该快照的SOURCE部分给出了一个最小但完整的 Roc 程序两行类型注解加上两个平凡实现构成整个测试的核心parse_a : Str - Try(I64, [BadA]) parse_a |_s| Ok(1) parse_b : Str - Try(I64, [BadB(Str)]) parse_b |_s| Ok(1) expect parse_a(1)? parse_b(1)?观察点有三parse_a返回Try(I64, [BadA])其中Try是 Roc 内建的双参类型构造器第二参数[BadA]是无载荷的标签联合tag unionparse_b返回Try(I64, [BadB(Str)])其 Err 分支BadB携带一个Str载荷顶层expect的两侧各自通过后缀?解包Try值随后比较解包出的I64。在普通函数体内?的 Err 类型必须与函数的返回类型统一而这里两个?的 Err 类型完全不同编译却完全通过——快照的EXPECTED与PROBLEMS均为NIL表示编译零诊断、零报告。这正是该测试要固化的语义expect不是函数没有返回类型可供 Err 统一于是每个 Err 类型被独立解包并丢弃互不干扰。为什么expect语境下 Err 不需要统一语义前提?文档 token 流中的NoSpaceOpQuestion在 Roc 中语义上等价于若成功则取出 Ok 载荷若失败则提前返回 Err。但提前返回需要一个返回目标在函数体内?的 Err 类型必须与函数声明的返回类型或其子类型兼容否则类型检查失败在顶层expect中不存在任何返回类型。此时编译器的行为退化为成功分支取出 Ok 值继续求值失败分支把 Err解包并丢弃unwrapped and discarded转而将整个expect判定为失败。于是两个不同 Err 类型[BadA]与[BadB(Str)]之间不需要任何统一关系它们各自沿着自己的失败分支走即可。快照 META 中的description精确概括了这一设计since each Err type is unwrapped and discarded rather than unified with a return type。从源码结构看这一语义在规范化阶段体现为一个专门的错误处理表达式——e-expect-err见下节脱糖细节它仅在expect上下文中由 Try 后缀脱糖产生与普通函数中的返回式错误传播在 src/canonicalize 目录中是分开实现的。规范化CANONICALIZE脱糖?如何变成 match expect-err快照的CANONICALIZE部分展示了?在规范化后的真实形态。以parse_a(1)?为例脱糖结果是一个e-match其条件表达式调用parse_a并包含恰好两个分支第一个分支匹配#okp-nominal-external (builtin)表示内建Try的Ok标签命中后取出载荷1e-lookup-local #ok第二个分支匹配#err命中后产生e-expect-err并把原始源码片段parse_a(1)?作为上下文信息(snippet parse_a(1)?)随错误表达式一并记录。parse_b(1)?在右侧以完全相同的结构脱糖只是对应#err的载荷类型是BadB(Str)。整个expect的两侧最终包裹在e-method-eq即比较之下。两个e-match的失败分支各自独立没有任何交叉统一从 IR 层面直接印证了每个 Err 类型被独立解包并丢弃的语义。这一脱糖形态与 src/canonicalize/test/try_suffix_test.zig 中的单元测试相互印证测试通过expectMatch辅助函数断言 Try 后缀脱糖后的表达式为e_match且is_try_suffix标记为真、分支数量恰为 2sliceMatchBranches(match.branches).len 2与快照中两个分支#ok与#err的结构完全一致。由此可以推断Try 后缀在规范化阶段是统一生成Ok/Err 双分支 match的标准脱糖而expect语境下的失败分支被专门路由到e-expect-err而非返回式传播。TOKENS 与 PARSE从词法到语法树的证据快照的TOKENS部分给出了完整的 token 流其中与本主题最相关的是最后一行KwExpect, LowerIdent, NoSpaceOpenRound, StringStart, StringPart, StringEnd, CloseRound, NoSpaceOpQuestion, OpEquals, LowerIdent, NoSpaceOpenRound, StringStart, StringPart, StringEnd, CloseRound, NoSpaceOpQuestion, EndOfFile关键信息?被词法分析为独立的NoSpaceOpQuestiontoken紧跟在实参右括号之后、OpEquals之前共出现两次expect关键字对应KwExpect字符串字面量被拆分为StringStart/StringPart/StringEnd三段。对应的PARSE部分则展示语法树形状顶层由两个s-type-annoStr - Try(I64, [BadA])与Str - Try(I64, [BadB(Str)])、两个s-decllambda 实现|_s| Ok(1)以及一个s-expect组成。在s-expect内部parse_a(1)?被解析为e-question-suffixTry 后缀表达式作为e-binop (op )的左操作数右侧同理。也就是说语法树上?直接挂接在expect的操作数表达式上从解析阶段起就没有任何返回类型的概念介入为后续规范化阶段走e-expect-err路径埋下伏笔。TYPES 与内建类型Try、I64 的推导确认快照末尾的TYPES部分给出类型检查结果(patt (type Str - Try(I64, [BadA]))) (patt (type Str - Try(I64, [BadB(Str)])))两个函数的类型与注解完全一致且规范化 IR 中Try通过(ty-apply (name Try) (builtin) ...)引用、I64/Str通过(ty-lookup ... (builtin))引用确认它们都是 Roc 内建类型。这带来两个直接推论Try作为内建类型构造器其 Ok 分支载荷I64在两侧解包后可直接用比较两侧e-method-eq的载荷类型均为I64BadA与BadB(Str)仅作为标签联合出现在各自函数签名中从不参与跨函数的统一这正是本快照能够零诊断通过的类型学原因。同主题快照串读?在 expect 中的完整行为矩阵该快照并非孤例test/snapshots目录下存在一组专门覆盖?在 expect 中行为的快照可串读以获得完整语义图景question_in_expect_err_type_unbound.md验证顶层expect中?的操作数约束为Try且Err 类型保持未绑定left unbound同样不存在返回式类型推导question_in_expect_no_unused_warning.md回归测试issue 9612确保expect内?脱糖出的 Err 载荷不会产生 UNUSED VARIABLE 警告——因为失败分支的载荷被解包并丢弃本就无意使用question_in_inline_expect.md 与 question_in_lambda_inside_expect.md分别覆盖内联expect与expect内 lambda 中?的等价行为。加上本文主角question_in_expect_mixed_err_types.md这组快照从Err 未绑定无未使用警告混合 Err 类型内联/嵌套位置四个维度把?在 expect 语境下的特殊语义钉死为编译器回归测试任何行为漂移都会在快照比对中现形。快照机制与运行验证本文件属于 test/snapshots 目录下的snippet 型快照。根据 test/snapshots/README.md快照测试通过捕获源代码在每个编译阶段词法、解析、规范化、类型检查等的输出来验证编译器行为并防止回归EXPECTED/PROBLEMS为NIL表示该源码编译产生零报告reporting.Report为空语义诊断快照与渲染输出快照分离管理普通快照typesnippet等只固定诊断语义渲染细节边框字符、ANSI、换行则属于reporting/目录的专用快照。如需在本地复现或更新该快照可运行Zig 构建环境# 生成全部快照 zig build run-snapshot-tool # 仅更新指定快照 zig build run-snapshot-tool -- test/snapshots/question_in_expect_mixed_err_types.md # 将 PROBLEMS 中的实际诊断回写为期望值 zig build run-snapshot-tool -- test/snapshots/question_in_expect_mixed_err_types.md --update-expected注意快照文件本身是只读的期望基准日常开发中不应手工修改只有在编译器行为被有意变更时才通过上述工具重新生成。小结三条可直接引用的结论?的语义是上下文相关的在函数体内它做返回式错误传播Err 与返回类型统一在顶层expect中它做解包并丢弃Err 无需统一两者在规范化阶段走不同路径e-expect-errvs 普通返回。混合 Err 类型合法且无需转换Try(I64, [BadA])与Try(I64, [BadB(Str)])可以在同一个expect中同时用?因为每个失败分支独立解包、独立丢弃载荷差异完全不参与统一。该行为有编译器级回归保护本文分析的快照及其同主题系列、try_suffix_test.zig 单元测试共同构成三重证据链任何偏离都会导致快照比对或单测失败。如果你正在阅读或贡献 Roc 编译器请以 question_in_expect_mixed_err_types.md 为最小复现单元结合 src/canonicalize 中 Try 后缀的脱糖实现和 try_suffix_test.zig 的断言来验证你对?语义的全部理解。【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考