Perl 5.10 中词法 $_ 的好处、坏处和丑陋之处

Question

从 Perl 5.10 开始，现在可以按词法限定上下文变量 $_ 的范围，可以显式为 my $_; 或在 given / when构造。

有人发现词法 $_ 的好用处吗？它是否使任何结构更简单/更安全/更快？

如果情况变得更加复杂怎么办？词法 $_ 是否在您的代码中引入了任何错误？ （由于写入 $_ 的控制结构将使用词法版本（如果它在作用域内），因此如果它包含任何子例程调用（由于动态作用域的丢失），这可能会更改代码的行为）

最后，我想构建一个列表，阐明何时使用 $_ 作为词汇、全局，或者何时根本不重要。

---

注意：从perl5-5.24开始，这些实验性功能是不再是 Perl 的一部分。

Answer 1

IMO，词汇 $_ 带来的一件伟大的事情是新的 _ 原型符号。

这允许您指定一个子例程，以便它将采用一个标量，或者如果没有提供，它将获取 $_。

因此，

sub foo {
    my $arg = @_ ? shift : $_;

    # Do stuff with $_
}

我可以写：

sub foo(_) {
    my $arg = shift;

    # Do stuff with $_ or first arg.
}

不是一个大的改变，但当我想要这种行为时，它会简单得多。移除样板是一件好事。

当然，这会产生更改几个内置函数（例如chr）原型的连锁反应，这可能会破坏一些代码。

总的来说，我欢迎词汇 $_。它为我提供了一个工具，可以用来限制意外的数据修改和函数之间奇怪的交互。如果我决定在函数体内使用 $_ ，通过对它进行词法化，我可以确定无论我调用什么代码， $_ 都不会被修改调用代码。

动态作用域很有趣，但大多数情况下我想要词法作用域。除此之外，$_ 也带来了一些复杂性。我听说过关于简单地执行 local $_; 的不可取性的可怕警告 - 最好使用 for ( $foo ) { } 代替。当我通过任何方式本地化 $_ 时，词汇化的 $_ 可以 100 次提供我想要的东西。词法 $_ 使极大的便利性和可读性功能更加强大。

我的大部分工作都必须使用 perl 5.8，因此我没有在大型项目中享受使用词法 $_ 的乐趣。不过，感觉这对提高 $_ 的使用安全性有很大帮助，这是一件好事。

Answer 2

我曾经发现一个问题（bug太严重了一个词）是我在使用 Inline 模块。这个简单的脚本：

use strict qw(vars subs);
for ('function') {
    $_->();
}
sub function {
  require Inline;
  Inline->bind(C => <<'__CODE__');
void foo() 
{
}
__CODE__
}

失败并显示 Modification of a read-only value attempts at /usr/lib/perl5/site_perl/5.10/Inline/C.pm line 380. 错误消息。在 Inline 模块的内部深处，有一个子例程想要修改 $_，从而导致上面的错误消息。

使用

for my $_ ('function') { ...

或以其他方式声明 my $_ 是解决此问题的可行方法。

（对 Inline 模块进行了修补以解决此特定问题）。

Answer 3

[理由：一个简短的附加答案，为可能路过的 Perl 新手提供快速摘要。当搜索“perl 词法主题”时，可以在这里结束。]

到目前为止（2015 年），我认为词法主题的引入（my $_ 和一些相关功能）导致了众所周知一些一开始就难以检测到的意外行为，因此标记为实验，然后进入 弃用阶段。

---

部分摘要 # RT119315：
一项建议是诸如 use feature 'lextopic'; 使用新的
词汇主题变量：
$^_。
另一点是“主题化运算符的隐式名称...除了 $_" 与显式词法函数结合使用时效果最佳（例如词法 map 或 lmap）。这些方法是否能够以某种方式挽救given/when尚不清楚。在实验和折旧阶段的来世，也许有些东西最终可能会在 CPAN 的河流中继续存在。

Answer 4

虽然我在涉及 Perls 魔法时倾向于遵循“不问，不说”的政策，但这里没有遇到任何问题。即，例程通常不会依赖于它们的同级使用非词汇数据作为副作用，也不会让它们这样做。

我已经针对各种 5.8 和 5.10 版本的 perl 测试了代码，同时使用描述 Camel 的 5.6 来偶尔参考。没有遇到任何问题。我的大部分工作最初是针对 perl 5.8.8 完成的。