[swift-evolution] [Pitch] Remove destructive consumption from Sequence
matthew at anandabits.com
Fri Jul 1 17:20:33 CDT 2016
> On Jul 1, 2016, at 11:54 AM, Dave Abrahams <dabrahams at apple.com> wrote:
> on Fri Jul 01 2016, Matthew Johnson <matthew-AT-anandabits.com <http://matthew-at-anandabits.com/>> wrote:
>>> 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).
> Yes, but requirements clustering is absolutely essential to creating
> coherent generic libraries. Otherwise you end up with a billion little
> granular protocols, to no real purpose.
>> 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.
> It might, but let's drop it. The only *real* reason we have it is to
> provide nice precondition checking for Range construction, and we can
> simply make that conditional on comparability.
Cool. This sounds like a good approach.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution