+1
我真的很想看到这种情况发生。
更具可读性，如用于索引的end 。

+1
2013 年 12 月 27 日下午 1:06，“GaborOszlanyi”通知@github.com 写道：

+1
我真的很想看到这种情况发生。
更具可读性，如用于索引的 end。

—
直接回复本邮件或在 Gi tHub上查看
.

我也喜欢这个建议。

我对它获得的支持的热潮感到有些惊讶。 我一直觉得拼写出来的操作符对于控制流来说更直观，但我没有意识到这种感觉很普遍。

当你提出这个提议时，我不是粉丝，但经过一些思考后我必须说这对我来说也很有意义。 与使用符号而不是文本的所有其他操作符相比，这些实际上是控制流操作符。 这可能会减少与&和|的混淆。

我注意到提供and和or （Perl、Ruby、Lua - 对于我检查的那些）的语言也提供not （Lua 甚至不提供! ）。 我的第一反应是我不喜欢它，因为它与!是多余的。 但也许这些语言选择这样做是有充分理由的。

我个人非常喜欢not ，但不要认为切换到not可以减少使用and和or提供的歧义。

not也不是短路/控制流操作，我总是在如何阅读关联性方面苦苦挣扎。 我在 Pyhton 中唯一喜欢它的地方是if not ...但那是因为我将其视为控制流操作。

+1

也可以添加异或作为短路？
和反向版本（XNOR，NAND，NOR）的短路版本？

XOR 永远不会短路。 其他的可以用!加上and和or运算符来简单地编写。

+1
我要指出的是，在 Ruby 中，&& 与“和”一直存在混淆（http://devblog.avdi.org/2010/08/02/using-and-and-or-in-ruby/），所以如果我们牢记 Ruby 用于拥有两组运算符的合理性，并决定是否值得混淆，或者是否应该完全删除 && 以支持“和”，那将会很好。

我希望and和or像在 Perl 和 Ruby 中那样具有超低的优先级，这样您就可以编写类似

k <= n and k *= 2

有时你想将布尔结果分配给某些东西：

cond = f() && g()

这似乎与此冲突。

嗯，这正是 Ruby 和 Perl 拥有两组具有不同优先级的运算符的原因。 不是提倡，只是说。 我不确定这种用法实际上有多普遍，而通过我们的代码 grep 揭示了很多k <= n && (k *= 2)类型的事情。

首先，我也支持and和or 。
我看到 Julia 现在最低的四个优先级组是

1. 赋值包括+=等， := ， =>和~
2. 三元运算符?
3. ||
4. &&

我认为这是有道理的（不确定~ ，但这无关紧要）。 逻辑and和or作为赋值的右侧和?条件都很有用。 如果您打算使用赋值或三元运算符作为and或or ，我想您知道您正在做一些不寻常的事情并且括号是有序的。

顺便说一句，我认为很多人会期望使用and和or进行逻辑运算的语言会使用not进行逻辑否定。 但是如果我们有充分的理由保留! ，那可能没问题。 （我猜!严格来说不仅仅是逻辑否定，至少如果 #4892 被实现是合并的。）

我会对not而不是!感到有点难过，但我会选择这里的任何内容。

我真的不认为not是类似的—— and和or是控制流操作符，而不是函数，而!只是一个函数。

我同意斯蒂芬。 not真正让你得到的唯一一件事就是不必使用尽可能多的括号。 我认为这是一个单独的问题。

我只是在谈论新用户的最初期望。 但我觉得
似乎有一个合理的理由可以保留！

我想相反。 相当多的语言使用 && 和 || ，包括我经常使用的所有语言，而那些总是短路的。 和/或我对它们是否短路没有直观的期望。 我也喜欢 && 和 || 与变量名称和数字在视觉上明显分开。

http://en.wikipedia.org/wiki/Short-circuit_evaluation 中的表格可能与本次讨论有关。

作为一个来自 Python 世界的人，我很惊讶地发现自己同意 @GunnarFarneback。 最近我发现英语条件（ and ， or ， not ）经常导致我写出我天真地期望工作的错误代码（因为它在英语）然后不得不挠头几秒钟，而我在意识到我的错误之前在精神上从英语转换为逻辑语句。 也就是说，我对任何一个方向都没有特别的偏见。 只需放入我的 2 美分。

我也支持and和or

+1

+1
有两个运算符
and和or具有弱优先级
我认为cond = f() && g()应该写成cond = (f() && g()) 。
我还支持使用具有弱优先级的not ，理由是!在我见过的每个上下文中都具有很强的优先级，需要if !(something and something)我在某些深层次上不喜欢它、非理性、不可改变的水平。 我也觉得!有时很难看到。 我也不知道!起源，但觉得它作为整数的阶乘运算符有更合适的位置——因此偏好 matlab 的~语法。

@johnmyleswhite这个问题被关闭了吗？ 我想这艘船已经在这艘船上航行了。

:(

短路那张皱眉的脸

我认为我们仍然应该考虑这一点。 很多人似乎不喜欢我们使用&&和||的方式，而更喜欢and和or 。 还有一个优先级问题，这使得&&和||有点尴尬。 我们可以转向一个未来，其中&&和||要求两个操作数都是布尔值，而and和or做&&和||事情x == nothing and x = 0等。 或者引入不同的单行条件语法，如x = 0 if x == nothing 。

最后一个语法x = 0 if x == nothing有一些 IMO 问题， https ://groups.google.com/forum/#!topic/julia -dev/cnmLcNg8h0Q 中的建议确实如此。
以下两个选项是否如此可怕以至于 Julia 需要后置条件？

    if x == nothing ; x = 0 ; end

或者

   x == nothing && (x = 0)

也就是说，就像我不介意在 Julia 中看到repeat ; expr(s) ; until cond构造一样（但没有它也可以生活），我不认为拥有and和or添加到 Julia。
与使用从 C &&和||借来的语法相比，它们似乎更适合 julia 语法。

我认为我们仍然应该考虑这一点。

+1

我对赋值的优先级低于||感到惊讶，所以我搜索了之前的讨论并发现了这个问题。 这没什么大不了的，但这些括号对我来说确实不合适。 我花了一段时间（我认为是几秒钟，并在 REPL 中进行了测试）才发现哪个分配位置无效。 - 错误消息指出函数定义结束后的行。

isempty(o) || (m.over[s][NULL] = o)

相比之下， cond = (f() && g())的括号在我看来没问题。 我想无论如何我都会使用它们。

对于它的价值，我也更喜欢and和or 。

我也是+1。

回应几乎一致赞成and等。我认为有两种反对意见，一种是无动于衷，另一种是未指明的，其他所有人（15 岁或以上）都赞成。

我认为反对（更难阅读）的一个论点是不正确的。 争论是foo and bar比foo && bar更难阅读，因为 3 个词 vs 词 SYMBOL 词。 然而，每个人都在使用语法高亮，在这种情况下，情况正好相反。 and是作为关键字着色的，所以a<1 and b>3实际上会着色，有利于在视觉上拆分左右子表达式，而a<1 && b>3所有三个运算符都将是相同的颜色，提示潜在的运算符优先级抓挠。

一个尚未提出的论点 _for_ 是布尔运算符作为单词具有优雅的一致性，因为运算的结果是true或false ，即也是一个单词。 因此，初学者很容易记住&与and的按位与逻辑。 记住&与&&要困难得多，因为它似乎是一个任意分配。 保证初学者会错误地使用& ，因为& and在英语中传达了

_for_ 的另一个可能的论点是大脑会自然地解析 {BUNCH OF SYMBOLS} 字 {BUNCH OF SYMBOLS}。

为什么不直接切换？ 现在总是做这件事的最佳时机，它永远不会比现在更容易。 修复当前使用 && 的代码并不难。

有and or not xor也许nand只是为了完整性？ 我不介意保留!的想法。 让程序员选择何时使用哪个。 没有错！ 话虽如此， !已经在foo!样式函数中使用了，所以有一些“最小化符号重用”的说法。

@StefanKarpinski似乎从 2013 年开始就赞成达成共识，我可以尝试实施这一点，但我担心是否会考虑这一点，因为这个问题尚未关闭，我认为这仍然是开放的讨论？ 使用这个词代替符号会很好地与isa作为中缀运算符一起使用，与true 、 false 、 end等相同。似乎这样更一致和可读。

+1

刚刚从 Python 进入 Julia。 似乎 Julia 有进入符号溢出的危险。 为了人类可读的代码，我强烈支持and和or

支持not关键字还可以提高代码的可读性。

我们是否应该分别在 0.7/1.0 中弃用/禁止使用and和or （可能还有not ），以便稍后我们决定添加这些真的喜欢他们吗？

我会失望的。 我敢打赌@JeffBezanson是反对的，但是如果我们现在不允许，我们以后可以随时改变主意并允许它，而我们不能走向另一个方向。 能够向尝试 Python 样式运算符的用户提供简单的“使用&&而不是and ”错误消息也可能会有所帮助。

我认为那会很棒！

重新打开并添加到里程碑以确保我们不会忘记。

我不明白里程碑的意图，我们要添加and和or吗？ 我们正在重新考虑吗？ 寻找这个的另一种用途？ 或者你的意思是你要添加警告之类的弃用，所以来自 Python 的人知道使用&&而不是and ？

我有https://github.com/JuliaLang/julia/pull/19788其中它们是别名，但我可以更改它以替换它们。

里程碑应该意味着：做出决定。 或者，如果我们无法及时做出决定，请弃用and和or任何使用，以便我们可以推迟决定，而不会冒着以后破坏任何人的代码的风险。

我明白，鉴于在几周内冻结代码的愿望，现在重新打开这罐蠕虫可能为时已晚（我很欣赏增加折旧为未来敞开大门的想法），但有一个想法：

当第一次讨论这个问题时（2013 年），我认为 Julia 社区主要是开发人员——具有强大 CS 背景的人，他们更习惯于使用&&和|| 。 我_怀疑_可能欣赏and和or大多是应用用户，他们对 ascii 沙拉不太满意，并且还没有花足够的时间在旧语言上完全习惯&&和|| 。 如果我们对当前的 Julia 用户进行民意调查（尤其是当我们在更多非开发人员可能会看到它的讨论中提出它时），可能会有兴趣了解人们对此的看法。

所提议的是保留and 、 or和not语法。 如果我们这样做，我们可以在 1.x 时间线的任何点添加这些作为操作符。 现在不需要进一步讨论。

我可以将这些解析为永久性语法错误，就像我们对**所做的那样。 但我仍然非常非常反对给他们任何形式的意义。

我也觉得很遗憾，我们正在挖掘已经做出决定的旧问题，尤其是在接近 1.0 的时候。

需要明确的是：如果有人这样做，这就会完成。

感谢您的澄清！ :D

在我看来，费心去解析它们并禁止其他用途，却让它成为一个语法错误，这似乎很愚蠢。 我认为大多数人宁愿没有and和or是保留字的情况（即在<strong i="7">@stackeval</strong> 1 0 and 1 or等上下文中不可用）但没有任何用处。 我建议要么根本不解析它们，要么将它们解析为别名（这并不罕见，因为 C 和 Ruby 就是这样做的）。

我们已经决定不将它们解析为别名，这就是 PR 被关闭的原因。 所以+1根本不解析它们。

冒着重新讨论这个令人厌烦的讨论的风险，我会注意到，关于 C 和 Ruby，在 C 中使用and和or在我的经验中是非常罕见的，并且最常见的 Ruby 风格指南需要&&和||而不是and和or 。

恕我直言：似乎最初的辩论相当分裂，添加这种保护只是为社区在他们想要的未来重新审视它留下了空间。

我不知道为什么要重新开放。

使用 JuliaParser.jl 可以轻松完成具有这种句法特征的 Julia 方言，一旦内部和元编程 API 稳定下来，就迫不及待了！ ：微笑：

对于那些在没有关注发生的事情的情况下遇到这个问题的人：虽然使用and和or的想法获得了相当多的支持 *)，但第一个解决这个问题的 PR - #19788 - 主要导致关于and和or是否应该直接替换&&和||或应该具有稍​​微不同的语义的讨论，例如关于优先，但只是让它们别名被认为是不需要的。 PR #24965 会保留关键字（连同not ），以允许在 1.x 周期中赋予它们一个含义。 然而，在分类呼叫期间的讨论导致不赞成，因此最早可以重新考虑的时间点是 2.0。 （人们可能需要提出一个真正令人信服的理由来让改变发生。）

*) 似乎提议的更改不太受更有影响力/“核心”开发人员的欢迎，因此仅查看 👍 的数量可能会产生误导。

我希望我没有过度简化并且把事情做对了。 如果我没有道歉。

所以最早可以重新考虑的点是 2.0。 （人们可能需要提出一个真正令人信服的理由来让改变发生。）

如果我们现在多次决定不这样做，我不明白为什么会发生这种情况。 我希望我们可以避免在每个主要版本中再次挖掘这个问题。

如果 Julia 坚持足够长的时间来与 Python 竞争，我可以保证这种情况会越来越多。 许多 Python 用户不想回到 C 语法。 这是 Python 如此受欢迎的众多原因之一：易于学习，使用上瘾，您不会想回到旧的做事方式。

新语言设计者经常声称他们想要用户友好的语法，但他们往往会迷失在只有一小部分用户想要或使用的奇特功能中，同时忽略了可能推动采用的简单调整。

举个例子：支持奇怪的 Unicode 运算符，但不and和or 。

R 还使用&&和||和 1-indexing。 它不仅仅是较旧的（或像 C 这样的低级语言）。 我对使用哪个无动于衷，但它并不难：我教过 R 和 Python 来完成初学者（没有编程差异），这不是他们努力解决的问题。 通常，与用于编写代码的符号或单词相比，基础概念更重要并且需要更多时间来学习。 作为 R、Python、C 等用户，“用户友好”和“直观”语法将因您已经熟悉的内容而有所不同。 对于绝对的初学者来说，情况并非如此，我们应该在这里更关注他们，因为我认为那些有其他语言编程经验的人具有处理新语言中不同约定的经验和专业知识。

似乎在这里提出的唯一原因是 Python 使用and和or以及类似的人。 换过来的麻烦值得吗？ Julia 不是 Python，也不应该尝试成为。 我们已经有了 Python。 为了给任何人切换到新语言的动力，它应该有所不同。 Julia 的新用户可能不是 Python 程序员，他们可能有使用不同语言的经验（或者如果它足够流行，则根本没有经验）。

我认识到这可能是一个死问题，但在回复@TomKellyGenetics 时，我建议恕我直言，我们中的许多人会认为 R 符合“较旧”的条件，而且它不是特别用户友好......虽然我同意初学者的观点， &&运算符“不是他们挣扎的东西”，我确实认为我教过的大多数学生都发现英语运算符（ and ， or ）更熟悉和可读，无论它们是 Python用户与否。

R 也使用 && 和 || 和 1 索引。 它不仅仅是像 C 这样的较旧的（或较低级别的）语言。

我指的是类 C 语言，即大量借用 C 语法的语言，通常带有自我实现的论点，即“它是所有其他语言使用的语法”。 R 语法有点像 C，尽管它在这里和那里有所不同。 Julia 更像 Fortran 而不是像 C，尽管有一些重叠。

我已经教过 R 和 Python 来完成初学者（没有编程差异），这不是他们努力解决的问题。

刚接触编程的 IME 学生在语法上挣扎，这是千篇一律的死亡。 编程是陌生的，选择抽象符号而不是自然语言使它更加陌生，更容易忘记。 我经常听到类似 C 语言的初学者问这样的问题：“你如何再次写出‘或’？”
但是编程中的自然语言不仅仅是初学者的问题。 即使是有经验的程序员也更有可能错过!而不是not ，许多人发现它更容易快速阅读和键入or和and不是||和&& 。

Julia 不是 Python，也不应该尝试成为。 我们已经有了 Python。 为了给任何人切换到新语言的动力，它应该有所不同。

Julia 也不是 C 或 Fortran。 绝大多数流行的语言都是类 C 语言，所以脱颖而出通常意味着做一些与 C 不同的事情。我实际上喜欢 Fortran、C 及其后代，一直使用它们，但在某些地方它们不够用，我认为我们可以做得更好。 使用更自然的语言是一种方法。 值得注意的是，Fortran 77 及更高版本使用.not. 、 .and.和.or.效果良好。 从这个意义上说，我实际上希望 Julia 更像 Fortran，而不像 C！

此问题已得到解决; and和or被允许作为标识符，我们将继续使用&&和||进行控制流。 我不确定为什么仍在讨论这个问题。

人们倾向于高估表面语法问题的重要性，因为它们高度可见，易于讨论，并且其含义通常很明确。 在另一个领域，除非代码块被大括号包围，否则一种语言被认为是不可用的，在这种情况下，julia 和 python 都无法使用。

我认为a and b是否确实比a && b更具可读性是有争议的。 &&更加突出。 ||和&&的长度相同的事实也可以导致更好的格式。 像a = b和a + b这样的运算符符号工作得如此出色的原因之一是它们在set a to b类的东西上添加了视觉结构。 a[i]或element i of a ？

你不会想回到旧的做事方式。

对我来说，旧的做事方式是手动内存管理和对多态性的弱支持，而不是&&的拼写。

Julia 有一些自然语言表达式，例如for a in [1, 2, 3] 。 这比 Julia 也支持的for a = [1, 2, 3]读起来更好，也更直观。 我当然不会建议我们为所有符号运算符提供自然语言替代方案，只有少数使 Julia 更直观和可读的。

FWIW，我投票赞成采用两组运营商，以简化采用并为用户提供风格选择。 在人们同时使用两者的 C++ 项目中，它从来没有困扰过我。 我看没有坏处，只有好处。

总的来说，我喜欢 Julia 语法的发展方向。 自然语言和符号之间的良好平衡，证明了数字语言可以在通用编程方面表现出色。 迫不及待地想看看它是如何成长和发展的。 这是我说添加自然语言运算符在技术上向后兼容的方式。 ：咧嘴笑：

我将尝试保留or 、 and和not以备将来使用，并发出警告/建议使用相应的符号。 我应该在 Julia 0.7、1.0 还是两者中都这样做？

24965？

啊，错过了，谢谢！ 我想不保留关键字不会阻止将来支持这些关键字。

对不起，阅读所有讨论，但仍然没有明白，我现在如何在 Julia 中使用and 、 or ？

你不能