说实话，我刚开始一点没觉得Swift哪里比OC好，即使是现在，我依然这么觉得，在用Swift的过程中，强类型语言确实让人很是头疼啊

第一个

otherButtonTitles
解释一下这个可选参数类型是Array<Any>?
UserArchive.unarchieveCommonThirdUserInfo()!.Site.keys
这行代码是表示解档出一个ThirdUserInfo对象并且取出Site属性，该属性类型为Dictionary<String, [String]>，然后取keys，按理说应该是返回Array<String>，或者至少也应该是个Array吧？然后报错了，这么写就是不对
报错是---- “Cannot convert value of type 'Dictionary<String, [String]>.Keys' to expected argument type 'Array<Any>?'”
翻译是---- “不能转换类型'Dictionary<String， [String]>的值。键'到预期参数类型'数组<Any>?'”

然后正确写法如下：

注意到我使用了Array()把它包起来之后才不会报错，难道这个是强转？haha....keys返回的居然还要强转成数组？？？嗯，6！

第二个

这个就比较牛逼了，前方高能，心理承受能力不足的勿看

为了让小伙伴们看的更清楚，我特意把这个拼接时间字符串的方法分成两个写法，注意看第一个写法报错，第二个不报错，但是它们最终如果能运行的话结果肯定是一样的，因为都是由year、month、day、hour、minute【也就是年月日时分啦】拼接而成

一直都听说Swift拼接字符串的操作比较骚，一个加号搞定一切？我这就多了几个加号而已，给我报错了，嗯，没事，咱们翻译一下报错，更好玩了

报错---Expression was too complex to be solved in reasonable time; consider breaking up the expression into distinct sub-expressions
翻译----表达式太复杂，不能在合理的时间内解决;考虑将表达式拆分为不同的子表达式。
嗯，表达式太复杂，报错了，对不起，Swift，我高估了你的运算能力，不应该写这么牛逼的代码的

第三个

大家应该都知道，Swift里面很多API都是借用的OC，所以我觉得说它基于OC也不为过，既然这样的话，说Swift比OC快的那我真的不知道是怎么想的了，然后，正因为借用OC的API，然后很多时候就会有这样的代码：

类型转化

然后你们懂得，后面用完还少不了一句 as String

第四个

Swift不能用宏，然后有人说宏可以用let常量来替换，那么，下面的宏你用常量替换一个我看看？

替换宏

替换成功一个算我输

然后又有人说了，你这是OC啊，OC和Swift可以混编的，哎呀，可别提混编了，我这个方法是类方法，然后我高高兴兴把这个文件拖进我的Swift工程，然后这方法死活打不出来，就是不提示，强行打出来还给我报错，然后没办法，只能新建了一个swift文件，把这个方法改写成Swift，当然，宏还是用不了的，变成这个样子

嘿嘿

还好我们还有判断啊，虽然写法丑了点，但是还好能用，唉.......

然后科普一下上面第四个里面用到一个Swift修饰Block关键字 @escaping关键字解释看这里

以上就是我写第一个Swift项目的时候遇到的一些问题，抒发的一些小感想，然后针对以上现象对刚开始写Swift的小伙伴们有几点小建议：

1、声明swift变量或者常量的时候直接说明类型，不要劳烦大佬去给你推断，它万一推断不出来给你来个表达式复杂你就改去吧
2、写表达式的时候不要写太长，例如我上面就年月日时分加上中间的空格和横杠间隔，一句表达式大概使用了8次相加，然后就复杂了，所以你们写个四五次就差不多了吧，它还是个孩子！！！
3、Swift与OC混编的时候，类方法少用，我上面那个不能用不是因为类方法名字里有宏所以不提示，还有其他的情况也说明了OC类方法混编的时候的确提示会有问题，没有对象方法反应快
4、如果你要是怕了，就不要用Swift了