[swift-evolution] Open Issues Affecting Standard Library API Stability

[Dmitri Gribenko]

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 <gribozavr at gmail.com>*/