随着Swift2.0引入的协议扩展、错误处理等新的强大功能的发布，这意味着Apple已经明确表示，他们非常积极地听取开发者社区的意见，以帮助完善并提高语言。我们对一些使用Swift的开发人员进行了调查，询问他们对下一个版本的Swift有何期望，因此他们将与我们分享他们对类型系统、协议和工具的想法。SashZatsLabgoo，Wondermall的iOS工程师、UX设计师和API架构师TypedErrors我的第一个希望是typederrors，虽然这个想法还不成熟，但是它可以给错误处理带来很大的改进。Swift2引入了新的错误处理机制，但不幸的是，与语言中的其他构造不同，错误构造不是类型安全的。这样做的好处是错误处理成为函数签名的一部分。比如dosomething()和dosomething()的throws类型不同，不能用前者代替后者；缺点是dosomething()throws无法指定它可以抛出的错误类型（如协议列表：throws）。依赖类型我的第二个期望是提供“依赖类型”（dependenttype）支持。这个想法在我的脑海里还没有完全形成，但我相信它会给现有的类型系统带来一种新的炫酷体验！它会对值类型本身加上限制，类型系统解析为：无类型数组->字符串数组->仅包含2个元素的字符串数组。这是对现有语言的一个非常有用的补充。下面的例子说明了这个函数在哪里更有用：classCar{varwheels:[Wheel]<4>=[Wheel(),Wheel()]//编译错误，类型不匹配，需要4个Wheel类型}Cocoa的TheSwiftfork***，我希望看到（但可能不会）看到Cocoa的Swift分支。虽然Cocoa是一个很棒的框架集合，但它本身承载的内容太多，可能会影响Swift的开发方式。我很乐意看到不需要引用的结构通常应用于新分支（在我的想象中，我认为UIBarButtonItem、UINavigationItem等类不应该需要你累积它们的状态，所以它们可以被替换通过一个结构）。因此，我们可以重新设计API，尽可能利用枚举中的关联值。在某些情况下，枚举可以更准确地描述它的作用：例如，UIDatePicker可以在属性中使用关联的枚举来表示其日期值和用于创建该值的模式。classUIDatePicker{enumValue{caseDate(date:NSDate)caseCountDownTimer(period:NSTimeInterval)}varvalue:Value?}这不太可能发生，因为这样的改变需要一个单独的团队为现有版本和新版本构建一个全新的API，这个过程需要付出很多努力。我知道这些想法对于Swift团队面临的实际问题和长期目标来说是非常幼稚的，因为整个社区都知道他们所做的事情很棒！JorgeOrtizPoWWaUFounder,MobileDevelopment开发者和教师BetterAuxiliaryTools希望有一套更成熟的辅助工具。例如，我希望有一个可以一直依赖的调试器，而不是时不时出错的调试器。此调试器可以显示当前堆栈帧中符号的实际值。此外，我希望有一个为Swift进行重构的编辑器，就像在Objective-C中所做的那样，这样我就可以在它的帮助下改进我的代码，比如将一些语句提取到方法中，或者重命名类的名称或项目中的方法。这个编辑器需要能够生成代码，让我免于代码例程（我不是指代码片段）。例如，如果编译器发现我的类或结构没有完全实现某个协议，我希望编辑器有一个选项可以自动根据定义创建缺少的方法。WellTested第二个愿望很简单，但却让做测试的人非常开心。我想在不使用模拟器的情况下运行测试，这样可以改善体验。如果一个类仅基于Foundation，那么应该可以在没有模拟器的情况下对其进行测试。这将减少需要运行的测试套件，使测试花费更少的时间。内省机制的第三个愿望与语言本身有关。我希望Swift有更好的反省（如果你愿意的话，反思）。另外，希望它有一个更动态的调度机制。没有这些功能，就无法创建模拟框架等工具。SamGiddinsUChicago2018。CocoaPods。捆绑器。高阶泛型首先我需要向大家道歉，因为你可能会反感我们骄傲的开发人员需要向Swift团队乞求我们希望的新Swift3特性。不过，我觉得实现这个功能才是最重要的，所以无论如何我都愿意去做。由于High-KindedTypes是一个很难理解的东西，我将使用我们最喜欢的函数式编程比喻——墨西哥卷饼来向你解释。我们知道，不管里面的内容如何，??我们都可以用同样的方式吃各种卷饼，因为卷饼本身只是一个包裹里面的馅料。但是，如果我们有一个方法可以告诉Swift，“这是一个对象，我唯一关心的是它是墨西哥卷饼，无论里面包裹着牛排、蔬菜还是虾，我只关心它是墨西哥卷饼。”然而，Swift并没有让你轻松实现。如果你想吃某种卷饼，首先需要这样做：“相同馅料的卷饼是一样的”。那样的话，你会发现你可以使用的墨西哥卷饼很少......我们不得不说Swift的上层结构类型不允许我们以这种方式表示它们。例如，没有任何方法可以编写可在该类型的所有实例中使用的Monad或Functor的定义，这意味着我们添加的每个新SequenceType都必须表示为S:EquatablewhenS.Element:Equatable形式。这造成了大量的代码重复，这意味着我们无法将我们的真正目的编码到类型系统中，导致我们的程序员犯更多错误并产生错误。JacobSchwartzGlint***工程师将Xcode与Swift版本脱钩我很高兴看到Swift语言发展到今天，我认为团队在预测我们的需求并向公众React提供反馈方面做得非常出色。对于Swift3.0，我希望能够使用来自不同版本Xcode的语言。我无法完全深入研究Swift2.0，因为它仅在Xcode7上可用，Xcode7放弃了对iOS7的支持。将Xcode（和iOSSDK）与Swift版本相关联会产生不必要的惯性，并阻碍开发人员迁移到新语法。所以不要难为我们选择，让我们一直用最好的语言！ViktorBelenyesiPrezi***iOS/Mac开发人员扩展中的存储属性就像Scala功能一样，如果我们可以通过扩展向现有类添加新的存储属性，那将是一个巨大的改进。我们可以用ObjC运行时来做到这一点，但这种代码对我来说感觉很糟糕，因为我每次都必须输入这些狗屎：extensionUIView{varmyTag:String?{get{returnobjc_getAssociatedObject(self,"myTag")as?String}set(newValue){objc_setAssociatedObject(self,"myTag",newValue,UInt(OBJC_ASSOCIATION_RETAIN))}}}AgnesVasarhelyiPreziiOS/Mac开发者定义泛型中的协变机制Built-intypesinSwift已经是协变的了，但是说到自己创建的party，一般来说，一定要在宾客名单中加入不同的人，否则设计会失败。SamRitchieCodeSplice***CodesplierconstrainedgenericprotocolconformanceSwift扩展有两个非常有用的功能，一个是增加协议一致性（protocolconformance），例如在Swift1中：?extensionString:JSONEncodable{functoJSON()->JSON{return.String(self)}}另一个是向协议添加通用约束的能力，例如在Swift2中：extensionArraywhereElement:JSONEncodable{functoJSON()->JSON{return.Array(self.map{$0.toJSON()})}}不幸的是，你不能将两者结合起来（即向受约束的泛型类型添加协议一致性），例如：extensionArray:JSONEncodablewhereElement:JSONEncodable这种写法无法编译。这意味着如果你试图使用“面向协议的编程”，你不仅需要避免使用泛型，而且还要花费大量的时间和精力来编写重载函数。如果这个特性可以在Swift3中实现，那么我相信它会节省大量的代码，并且让协议和泛型更有用。IttyBittyApps和TheCocoaBots的***开发者我对这门语言本身并没有太大的期望，但是如果像C#这样的语言有一个异步风格的函数（Async-StyleFunction），那就太好了向上。但我最希望看到的是更好的无障碍工具。在Xcode中使用Swift仍然是一个痛苦，例如我不能使用重构，这让我感觉我在使用几十年前的IDE。如果有更好的工具和更清晰的错误信息就好了。此外，我希望在明确要求Optional.None的情况下禁用nil，但听起来我太醉了，无法提出这个建议。老实说，我还没有真正想过Swift3.0会是什么样子。标准库已经很好很简洁了，如果它缺少什么，你实际上可以自己构建它。BenjiEnczMakeSchool工程师，即将推出PlanGridTypedErrorHandling我最希望看到的是函数抛出它们可能生成的错误类型。目前Apple的建议是将这些错误类型写在函数的文档中，但如果编译器也知道这些错误类型不是更好吗？这允许精确的错误处理，而不是使用一个包罗万象的错误陷阱。这也允许API中容易出错的函数更好地表达自己。
