Hi swift-evolution, Dave, Max and I have compiled a list of open issues in the standard library for which the resolutions could result non-additive API changes. Having a resolution (and an implementation of the resolution!) for these issues is blocking API stability.
https://gist.github.com/gribozavr/37e811f12b27c6365fc88e6f9645634d This is not an exhaustive list. The first two sections ("Low-Hanging Fruit" and "Moderate") list issues with low and moderate difficulty. It should be possible to resolve them with minimal design work. **We are strongly encouraging the community to pick up these issues. Please do not reply to this thread. Instead, start a new thread for the issue you would like to discuss, and include the original description and the bugs.swift.org link in your email.** For the issues in the "Hard" section, we would like to post the following commentary: - The issue about algorithms not marked mutating consuming a single-pass Sequences. We have figured out a design that we think is a good trade-off. We will post it for public discussion within a few days. - An extension to the collections subsystem that would allow us to model infinite data streams. We think that the answer to this problem should try hard to handle both single- and multi-pass collections, or provide a very convincing explanation why it is desired to enable only one of them (only multi-pass or only single-pass) to be infinite. We see four possible solutions to this problem: 1. No change (disallow infinite data streams). 2. Allow infinite single-pass streams (as Iterators) and infinite multi-pass streams (as Collections). 3. #2, and, for QoI, to catch mistakes in a non-guaranteed, best-effort fashion, add a property 'isKnownToBeInfinite' or 'isKnownToBeFinite' that would be checked before the whole dataset is iterated. If the dataset is known to be infinite, issue a trap. 4. #2, and introduce new protocols for finite iterators and finite collections. Unfortunately we don't have time to investigate the question about infinite collections further. We suggest interested community members to drive the discussion on this topic. - Dave Abrahams has been investigating whether it would be an improvement to remove Comparable requirement from collection indices, he will post an update separately. - Naming of algorithms on sequences and collections is important, and we are thankful for the community for working on these issues. We hope that these efforts would result in proposals! - The spaceship <=> operator is an important, but also complex topic. If someone wants to work on this item, we think that writing a prototype and showing how it integrates with existing code, investigating whether it solves issues with floating point min() and NaNs, figuring out what the migration experience is etc. is critical before opening a discussion. The general design direction is clear -- we want to require users to define just one operator, <=>, to conform to Comparable, but there are many details that would only be found in a prototype implementation. These small issues need concrete answers. I'd like to thank the community again for all work that you are doing, and encourage to pick up the issues from the list, and start discussions in new threads. I'd like to emphasize low and moderate difficulty items. We believe that for these issues the design space is small, and consensus can be reached without a lot of discussion. The associated API changes have a good chance to land in Swift 3.x. Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <griboz...@gmail.com>*/ _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution