I have nothing against reactive programming, but I don't agree that a reactive library should be an official Swift.org project focus in the near future.
- Lower-level concurrency has already been described as a more pressing matter than any sort of opinionated higher-level framework, and will already require significant effort (no matter what form it takes) to implement, both in the form of language changes as well as rewriting the standard library (and to a lesser extent, Foundation) to take advantage of the new constructs. As well, it's likely that a reactive programming framework's design would be greatly dependent on how native Swift concurrency ends up being implemented. - I don't think the compiler team bugfix rate is constrained by lack of bugs to fix. More importantly, I don't think compiler bugs affecting a certain project should be privileged over those affecting other projects unless there is an extremely compelling reason to do so. Otherwise, there isn't a need for 'tighter feedback' - anyone can file bugs on the Jira as it is. - Given that all the important parts about Swift are open-source and available for public examination, I don't think there is any special system knowledge to be gained by conferring 'official' status upon a project. Rather, projects should propose features and enhancements they feel are both beneficial to their specific use cases as well as useful to the wider community, and then take advantage of those features to provide better APIs. - There are already widely-used non-official frameworks which provide this functionality. I think the benefit of providing an 'official' implementation would have to be extremely large in order to justify allocating Swift project resources towards duplicating the community's work. I think a better approach would be to determine what sort of criteria would justify the Swift.org project blessing any non-fundamental library with 'official' status (e.g. logging, web servers, cross-platform UI, whatever), and then using those to justify why Swift should officially support a reactive library. Best, Austin > On May 10, 2016, at 12:41 AM, James Campbell via swift-evolution > <[email protected]> wrote: > > With swift 3 around the corner, I wanted to propose some higher level focuses > for version 4. > > My first suggestion is an official reactive library. Reactive programming has > gained a huge amount of popularity especially with reactive cocoa and rxswift. > > Microsofts support of the original Rx library is a big help in this. > > I believe the apple ecosystem would benefit from offering this same support > to an official library, why? > > - RxSwift in particular is pushing the limits of the compiler and often > crashes source kit. I believe if we had an official library we could have > tighter feedback to the compiler team. > - it would help address the complexities of async code without reinventing > the wheel. > - it could reduce app size. RxSwift is a large framework right now but I > would imagine with the right system knowledge it could be refined and the API > simplified with an official library. > > Let me know your thoughts > > Sent from Supmenow.com <http://supmenow.com/> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
