让赋值运算符返回值有什么好处？

我正在开发一种语言，打算取代Javascript和PHP。（我看不出有任何问题。这两种语言都不具有庞大的安装基础。）

我要更改的一件事是将赋值运算符转换为赋值命令，从而取消了使用返回值的功能。

x=1;          /* Assignment. */
if (x==1) {}  /* Comparison. */
x==1;         /* Error or warning, I've not decided yet. */
if (x=1) {}   /* Error. */

我知道这将意味着C员工如此钟爱的单行功能将不再起作用。我发现（几乎没有我个人经验的证据），这种情况在绝大多数情况下确实是比较操作。

还是？赋值运算符的返回值是否有任何实际用途，无法轻易重写？（对于具有这种概念的任何语言。）

从技术上讲，即使语法语法糖可以提高一些常规操作的可读性，即使可以简单地替换掉，它也值得保留。但是，分配即表达不属于此范围。在比较中输入错误的危险意味着它很少使用（有时甚至受到样式指南的禁止），并且每次使用时都会引起重复。换句话说，可读性的好处是数量和幅度都较小。

看看这样做的现有语言可能是值得的。

• Java和C＃保留赋值表达式，但通过要求条件评估为布尔值来消除您提到的陷阱。尽管人们偶尔会抱怨说这不允许if (x)在诸如if (x != null)或if (x != 0)取决于的类型之类的x。
• Python将赋值指定为正确的语句，而不是表达式。更改此建议的建议偶尔会到达python-ideas邮件列表，但我的主观印象是，与其他“缺少”功能（例如do-while循环，switch语句，多行lambda，等等

但是，Python允许一种特殊情况，即一次分配多个名称：a = b = c。这被视为等同于的语句b = c; a = b，并且偶尔使用，因此也有必要添加到您的语言中（但我不会费力，因为该添加应向后兼容）。

赋值运算符的返回值是否有任何实际用途，无法轻易重写？

一般来说，没有。将赋值表达式的值作为已赋值的想法意味着我们有一个表达式，可用于其副作用和其值，并且很多人认为这令人困惑。

常用用法通常是使表达式紧凑：

x = y = z;

在C＃中具有“将z转换为y的类型，将转换后的值赋给y，转换后的值是表达式的值，将其转换为x的类型，赋给x”的语义。

但是在声明上下文中，我们已经处于命令性副作用的境界，因此与

y = z;
x = y;

与

M(x = 123);

简写

x = 123;
M(x);

同样，在原始代码中，我们同时使用了一个表达式来表示其副作用和其值，并且我们正在制作一个具有两个副作用而不是一个副作用的语句。两者都臭。尝试使每个语句具有一个副作用，并使用表达式作为其值，而不是其副作用。

我正在开发一种语言，打算取代Javascript和PHP。

如果您真的想大胆地强调赋值是一个语句而不是一个等式，那么我的建议是：明确指出赋值语句。

let x be 1;

在那里，完成。要么

x <-- 1;

甚至更好：

1 --> x;

甚至更好

1 → x;

绝对不可能将它们与混淆x == 1。

许多语言确实选择使赋值成为语句而不是表达式的途径，包括Python：

foo = 42 # works
if foo = 42: print "hi" # dies
bar(foo = 42) # keyword arg

和Golang：

var foo int
foo = 42 # works
if foo = 42 { fmt.Printn("hi") } # dies

其他语言没有赋值，而是有范围的绑定，例如OCaml：

let foo = 42 in
  if foo = 42 then
    print_string "hi"

但是，let是表达本身。

允许赋值的好处是我们可以直接在条件中检查函数的返回值，例如在以下Perl代码段中：

if (my $result = some_computation()) {
  say "We succeeded, and the result is $result";
}
else {
  warn "Failed with $result";
}

Perl另外将声明的范围限定为该条件，这使其非常有用。如果在没有声明新变量的情况下在条件内部赋值，if ($foo = $bar)也会发出警告- 会警告，if (my $foo = $bar)不会。

通常在另一条语句中进行赋值就足够了，但是会带来范围界定问题：

my $result = some_computation()
if ($result) {
  say "We succeeded, and the result is $result";
}
else {
  warn "Failed with $result";
}
# $result is still visible here - eek!

Golang在很大程度上依赖于返回值进行错误检查。因此，它允许条件语句执行初始化语句：

if result, err := some_computation(); err != nil {
  fmt.Printf("Failed with %d", result)
}
fmt.Printf("We succeeded, and the result is %d\n", result)

其他语言使用类型系统禁止条件内的非布尔表达式：

int foo;
if (foo = bar()) // Java does not like this

当然，使用返回布尔值的函数会失败。

现在，我们已经看到了防止意外分配的不同机制：

• 禁止将赋值作为表达式
• 使用静态类型检查
• 分配不存在，我们只有let绑定
• 允许初始化语句，否则不允许分配
• 禁止在没有声明的条件内分配

我已经按照偏好的升序对它们进行了排序-表达式内的赋值可能是有用的（并且通过使用显式声明语法和不同的命名参数语法来规避Python的问题很简单）。但是也可以禁止它们，因为还有许多其他选择可以达到相同的效果。

无错误的代码比简洁的代码更重要。

您说：“我发现（几乎没有我个人经验的证据），这种情况在绝大多数情况下确实是比较操作。”

为什么不解决问题？

为何不使用==进行分配和==进行相等性测试，为什么不使用：=进行赋值并且使用=（甚至==）进行相等性测试？

观察：

if (a=foo(bar)) {}  // obviously equality
if (a := foo(bar)) { do something with a } // obviously assignment

如果要使程序员更难将分配错误等同于相等性，请使其更难。

同时，如果您确实要解决此问题，则可以删除声称布尔值只是具有预定义符号糖名称的整数的C缸。使其完全不同。然后，而不是说

int a = some_value();
if (a) {}

您强迫程序员编写：

int a = some_value();
if (a /= 0) {} // Note that /= means 'not equal'.  This is your Ada lesson for today.

事实是，作为操作员的分配是一个非常有用的结构。我们没有消除剃须刀，因为有人割伤了自己。相反，吉列国王（Kill Gillette）发明了安全剃刀。

要实际回答这个问题，是的，尽管它们有些小众，但它有许多用途。

例如在Java中：

while ((Object ob = x.next()) != null) {
    // This will loop through calling next() until it returns null
    // The value of the returned object is available as ob within the loop
}

不使用嵌入式分配的替代方法需要在ob循环范围之外定义，并使用两个单独的代码位置调用x.next（）。

已经提到您可以一步分配多个变量。

x = y = z = 3;

这种事情是最常见的用法，但是富有创造力的程序员总是会想出更多的东西。

因为你能弥补所有的规则，为什么现在让交作业的值，根本不容许有条件的步骤内分配？这使您可以轻松完成初始化的语法糖，同时仍可以防止常见的编码错误。

换句话说，将其合法化：

a=b=c=0;

但这是非法的：

if (a=b) ...

听起来，您正在创建一种相当严格的语言。

考虑到这一点，迫使人们写：

a=c;
b=c;

代替：

a=b=c;

似乎可以阻止人们这样做：

if (a=b) {

当他们打算这样做时：

if (a==b) {

但是最后，这种错误很容易检测到并警告它们是否为合法代码。

但是，在某些情况下会这样做：

a=c;
b=c;

并不意味着

if (a==b) {

会是真的。

如果c实际上是函数c（），则每次调用它都可能返回不同的结果。（它也可能在计算上也很昂贵...）

同样，如果c是指向内存映射硬件的指针，则

a=*c;
b=*c;

两者可能会有所不同，并且在每次读取时也会对硬件产生电子影响。

硬件还有许多其他排列方式，您需要精确地读取，写入特定时间限制并在特定时间限制下读取哪些存储器地址，其中在同一行上进行多个分配是快速，简单和明显的，而没有时序风险临时变量介绍

在我看来，将赋值作为一种表达的最大好处是，如果您的目标之一是“一切都是表达”，那么它将使您的语法更加简单-特别是LISP的目标。

Python没有这个。它具有表达式和语句，赋值是一个语句。但是因为Python将lambda表单定义为单个参数化表达式，所以这意味着您无法在lambda中分配变量。有时这很不方便，但不是一个关键问题，这是我的经验中让赋值成为Python语句的唯一缺点。

在不引入if(x=1)C 潜在事故的情况下，使赋值（或赋值的效果）成为表达式的一种方法是使用类似LISP的let构造，例如(let ((x 2) (y 3)) (+ x y))用您的语言将其评估为5。let如果您定义let为创建词法范围，则从技术上讲，完全不需要使用这种方法来分配语言。通过这种方式定义，let可以使用与构造和调用带参数的嵌套闭包函数相同的方式来编译构造。

另一方面，如果您只关心if(x=1)大小写，但是希望赋值像C中那样是一个表达式，则也许只需选择不同的标记就足够了。作业：x := 1或x <- 1。比较：x == 1。语法错误：x = 1。

我知道这将意味着C员工如此钟爱的单行功能将不再起作用。我发现（几乎没有我个人经验的证据），这种情况在绝大多数情况下确实是比较操作。

确实。这并不是什么新鲜事，C语言的所有安全子集都已经得出了这个结论。

MISRA-C，CERT-C等均禁止在内部条件下进行分配，仅因为这很危险。

在任何情况下，都无法重写依赖于内部条件分配的代码。

此外，此类标准还警告不要编写依赖评估顺序的代码。在单个行上进行多次分配x=y=z;就是这种情况。如果具有多个分配的行包含副作用（调用函数，访问易失性变量等），则您将不知道首先发生哪种副作用。

计算操作数之间没有序列点。因此，我们无法知道子表达式是y在之前还是之后进行求值的z：它是C中未指定的行为。因此，此类代码可能不可靠，不可移植且与所提到的C的安全子集不符。

解决方法是将代码替换为y=z; x=y;。这增加了一个顺序点并保证了评估的顺序。

因此，基于这在C中引起的所有问题，任何现代语言都可以很好地禁止在内部条件中进行赋值以及禁止在一行中进行多个赋值。