[swift-evolution] [Pitch] Remove destructive consumption from Sequence
Matthew Johnson
matthew at anandabits.com
Fri Jul 1 10:59:36 CDT 2016
> On Jul 1, 2016, at 9:47 AM, Dave Abrahams <dabrahams at apple.com> wrote:
>
>
> on Fri Jul 01 2016, Haravikk <swift-evolution-AT-haravikk.me> wrote:
>
>>> On 30 Jun 2016, at 23:39, Dave Abrahams <dabrahams at apple.com> wrote:
>>> All multi-pass sequences can benefit from subscripts.
>>
>> Sorry, not really what I meant, but rather; how many sequences are
>> really going to use them?
>
> The subscript and index aren't there for the sequence's benefit, and you
> can't know how users will want to use the sequence. The whole point of
> making a type conform to a generic protocol is that you can't anticipate
> all of the type's uses, so you want to make it work with as much other
> code as possible. If I'm defining a new sequence type, how can I know
> whether someone might want to use index(of:) or slicing on it?
This isn’t entirely true. Sometimes we know *exactly* how a type will be used in an application. It conforms to a generic protocol in order to take advantage of pre-existing generic code (algorithms, etc) in the standard library (or other libraries).
If the library contains algorithms expressed in terms of the weakest constraints possible (i.e. the current `Sequence` algorithms) sometimes we can accomplish what is necessary without needing to implement additional members on our type, even if it is possible to implement them and theoretically useful (but not useful to the current requirements of the application).
That said, I generally like the direction you suggesting.
I have been considering the incremental complexity of conforming to `Collection` rather than `Sequence` carefully. The one place that I still need to think further about is the `Comparable` requirement on indices and whether that might lead to nontrivial complexity over a `Sequence` conformance.
-Matthew
>
> --
> Dave
More information about the swift-evolution
mailing list