为什么没有在Swift 3中重新命名viewWithTag和其他一些方法？

Question

在Swift 3中，很多方法都被重命名了。根据WWDC的其中一个会话，方法名称中的介词将移动到参数名称：

UIView.animateWithDuration(1)
 -> UIView.animate(withDuration: 1)

UIStoryboard.instantiateViewControllerWithIdentifier("some stuff")
 -> UIStoryboard.instantiateViewController(withIdentifier: "some stuff")

所以我认为viewWithTag(1)将重命名为view(withTag: 1)，但它不是！

API指南中甚至提到：

  

特别是当参数类型是NSObject，Any，AnyObject或基本类型（如Int或String）时，在使用点处键入信息和上下文可能无法完全传达意图。在这个例子中，声明可能是明确的，但使用网站是模糊的。

func add(_ observer: NSObject, for keyPath: String)
grid.add(self, for: graphics) // vague

     

为了恢复清晰度，在每个弱类型参数之前加上描述其角色的名词：

func addObserver(_ observer: NSObject, forKeyPath path: String)
grid.addObserver(self, forKeyPath: graphics) // clear

我还发现SKNode.addChild也没有重命名！

问题：

为什么不重命名这些方法？他们忘了他们？或API指南有例外情况吗？如果是的话，他们是什么？

Answer 1

我正在研究Swift Evolution 0005中描述的算法。

1. 的 viewWithTag

名称修剪的第一步是：

  

  

1. 从类型保留变换的头部修剪结果类型。   具体来说，何时

        
     
   • 接收方类型与结果类型
   相同   
   • 并且类型名称在第一个选择器块的头部匹配
     
   • 并且匹配后跟介词
     
  

view部分实际上是第一个要删除的部分。

在步骤3中也删除forTag，因此结果为空选择器。

与

发生冲突

  

修剪限制   ...

     

  
• 永远不要让选择器片完全空着。
  

因此不会进行修剪。

1. 的的addChild

addChild，addSubview，addGestureRecognizer遵循所有相同的模式，规范中实际有一个例子：

  

  
• 永远不要从与封闭类的属性匹配的方法的基本名称修剪后缀：
  

     

这种启发式方法可以防止我们为概念上修改类属性的方法生成过于通用的名称。

     

...如果我们放弃GestureRecognizer，只留下add，我们最终会得到一个概念上修改gestureRecognizers属性但使用过于通用名称的方法：

一般来说，他们不能忘记某些方法，因为重命名（导入）是自动的。