得知SWIFT最近采用了Smalltalk关键字语法：[接受]SE-0279：多个尾随闭包，我非常惊讶。也就是说：关键字以冒号结尾，后跟参数，不带任何大括号。令人难以置信。一点。当然，如果这不是特殊情况的特例，特别是多个尾随闭包的特例，这是尾随闭包的一个特例，那么SWIFT就不会成为SWIFT，这是奇怪和特殊的-Casey本身就足够了。下面是一个示例：请注意Animate()的参数似乎在结束括号处终止，但事实并非如此。结束Paren之后的花括号开始了一个闭包，该闭包实际上也是该方法的一个参数，即所谓的尾部闭包。我对这个构造有一点同情，因为圆括号内的闭包看起来真的很别扭。(当然，f(X)中除了唯一的x之外的所有参数看起来都很别扭，但我们不要吹毛求疵。目前。)。这使得另一件事是方法合理地类似于控制结构，我听说这是一个非常好的想法。问题是，有时您有多个闭包参数，然后只是将它们堆叠在函数/方法调用的末尾，这会非常非常尴尬，而且您无法区分哪个块是哪个参数，因为尾随的闭包没有得到关键字。嗯，现在是这样了。我们现在将4种不同的方法语法放在一起！这是令人印象深刻的，以一种可怕的方式。SWIFT是一种特殊情况的发展趋势，其结果是语义上的复杂性、行为上的复杂性(即错误)和使用上的复杂性(即变通方法)。
我明白这项提议颇具争议性，反对者和支持者之间进行了激烈的讨论。我理解并同情双方。一方面，这明显好于其他选择。另一方面，这是一个特殊情况的特殊情况，很难证明它是对已经存在的所有东西的补充。特殊情况产生特殊情况，特殊情况产生特殊情况。当然答案总是存在的：在这种情况下，SmallTalk关键字语法不仅是唯一合理的解决方案，它还可以解决所有其他情况。这是一般的解决方案。在这里可以看到Objective-Smalltalk(它使用花括号代替Smalltalk的方括号来表示闭包)：没有特殊情况，每个参数都有标签，括号内没有语法杂乱等等。是的，这也处理用户定义的控制结构，to：do：只是NSNumber上的一个方法：而且由于关键字自然位于它们的参数之间，因此不需要将运算符作为。您只需允许一些"；BINARY&34；关键字看起来稍有不同，所以不是2乘：3，而是2*3。当您有2个提升到：3而不是POW(2，3)(带有签名：函数幂(_x：decimal，_y：int)->；Decimal)时，是否真的需要不厌其烦地定义"；运算符"；？或者是SWIFT的a as b，这是另一种特殊的语法。A、A、B怎么样？(是的，我知道有细节，但这些都是……。详细信息。)。以此类推。当然，现在已经太晚了。当我选择Smalltalk作为已经变成Objective-Smalltalk的语言的基本语法时，不仅仅是因为我喜欢它或者已经通过Objective-C习惯了它。SmallTalk的语法出奇地灵活和通用，Smalltalk API看起来很像DSL，没有任何工具或其他开销。这就是令人沮丧的部分：这些东西过去和现在都是可以买到的，而且是众所周知的。至少如果你不厌其烦地看和/或问一下。相反，我们只是随意地选择这些东西，每个人都要承受后果。