if的用法比较蛋疼

[HerringtonDarkholme]

比如

div.test if test

这一句是可以编过的

但是

div.test @new-attr="whatever" if test

就是编不过的
这个又是一个需要记忆的用法

jedi里if,else的用法本身也有三种，作为instruction，作为后置条件，作为表达式，同一个token在不同环境下承担不同职责是不好学，不好找，不好记的 (极端的例子)

另外在长远看来，if后置的条件判断一定会变长，而一般开发的习惯一定是把条件全塞进一个if里（coffeescript是个先例）

[hax]

本来只允许简单情况下后置if就是为了避免单行代码过于复杂。（问题是也许应该以警告代替直接parse错。）
在加入对binding的后置if支持（实际上是表达式支持后置if）前，一定会先加入某种程度的complexity测量和告警。

一个关键字有多种用途是不可避免的，这个case里换个关键字只有更不好记。设计上优先考虑的是use cases的需求，其次是不容易出错。

[HerringtonDarkholme]

不，这个就是多出来的事儿
去掉后置if，省掉了复杂度测量，省掉开发者记忆负担，省掉一个关键词用途

如果能把if在表达式里的东西换成 三元运算符，那if整个就只有一个意思了

[hax]

如果能把if在表达式里的东西换成 三元运算符，那if整个就只有一个意思了

三元运算符?:（相对 if ... then ... else）辨认起来困难。且征用了?和:两个重要符号，会对语法扩展造成潜在问题。（如js很难加入?.运算符。）
if ... then ... else是一个更可读的三元运算符语法。

去掉后置if，省掉了复杂度测量

复杂度测量是一个一般特性。所有表达式都有可能写得过于复杂。此特性最好由lint提供。但jedi将一些coding style的控制直接内置到了语法中。
之所以我希望在加入对binding的后置if支持之前先有复杂度测量，是因为目前的语法限制了一行里有后置if，只有一个表达式；而加入binding的后置if，就有两个表达式（binding本身就是一个表达式）。但复杂度测量这个需求本身并不是因为后置if才有的。

省掉一个关键词用途

后置 if 并没有创造一个新的用途，只是在普通的 if condition then expression 之外提供了 expression if condition 的语法。perl/ruby/coffee都有后置if，连python都有，所以我不认为这有多大的记忆负担。

[HerringtonDarkholme]

首先可读性是主观的，在js/php流行的公司用三元运算符比python式的 if then else更可读
?.运算符难加不意味着不能加，比如php7就加上了。而且就算现在好加了也没有啊

后面两点是同一个问题，加了后置if就有新的规则要记忆：有复杂度测量，语法限制后置if只有在某些dom里可以用

省掉一个关键词用的位置就是省掉一个复杂度，而且这个复杂度省掉了也不会引起太多不便。就算不是记忆负担，但是在写的过程可以少一个选择，改的过程少一个可能的改动，读的时候少一个需要注意的点（尤其是没有代码高亮的时候）

[hax]

在js/php流行的公司

这个是考虑因素，所以大部分地方都考虑了和js和php的一致性。但是不可能因此就禁止所有不在js/php里的东西。比如 for...in 跟js（for...of）和php（foreach ... as）都不一样，但是其实for...in更符合大多数人的直觉。

比如php7就加上了

php7加的是??，那是没有冲突的。但是如果它要加?->就不是那么简单的事情。而x?['key]就非常讨厌，因为有歧义。

就算现在好加了也没有啊

jedi的parser是支持?.的。没有完整的功能是因为语义和对应的compile结果我还没有想清楚。你如果有proposal可以提哈。