> PROPOSING: Update WatchKit API Design to use properties instead of methods to > set properties
swift-evolution does not control how specific Apple frameworks, like WatchKit, get exposed to Swift. We sometimes review proposals from framework teams like Apple and LibDispatch on how they want to expose their APIs, but the details are still up to them. If you want to influence the design of Apple frameworks, the best way to do that is still Radar <https://bugreport.apple.com>. As for your specific proposal, the main problem I see with this is that these WatchKit classes offer only setters, not getters, and Swift doesn't support setter-only properties. Adding that support would not be very compatible with value types, because we need to be able to access the existing value in order to mutate it. I have nothing to do with the development of WatchKit, so I'm speculating, but I believe this design was chosen so that user interface updates could be asynchronous. Currently, nothing I can think of in WatchKit ever uses a return value; supporting getters in these APIs would run counter to that goal. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
