[swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Dave Abrahams]

on Mon Apr 11 2016, Brent Royal-Gordon <brent-AT-architechies.com> wrote:

>>> If these types are for implementation sharing, should they be
>>> underscored to discourage their use? Or is the position they occupy in
>>> the type hierarchy important because Range and ClosedRange will
>>> eventually occupy them?
>> 
>> Underscoring hides names from users completely, and IMO that would not
>> be appropriate here.  If we underscored them, it would be mysterious
>> where an implementation of various methods came from.
>
> If the concrete types show these members, does it matter that they
> actually came from a protocol?

I don't know; would the concrete types show these members?

>>> On the other hand, it's not like the SubSequence subscript now takes a
>>> RangeProtocol. Should it?
>> 
>> No; subscript can't be generic (language limitation).
>
> Right, and RangeProtocol isn't existential. Ouch.
>
>>>> func successor(of i: Index) -> Index
>>> 
>>> Two things:
>>> 
>>> 1. I would really like a version of this which returns Optional and is
>>> guaranteed to go `nil` once it hits `endIndex`. 
>> 
>> The primary question to answer when exploring this idea is, IMO, “what
>> does that do to the code in algorithms?”  I can't imagine writing binary
>> search, partition, or rotate if I had to check for nil every time I
>> moved an index.
>
> If you're confident you're remaining in bounds, you should
> force-unwrap it.

s/check for nil/force unwrap/

>>> There can be a non-optional version too, or it might even be a feature
>>> of the `index` family of methods instead of `successor` itself, but I
>>> think it would be valuable to let the collection worry about the
>>> bounds check.
>> 
>> Why would that be valuable?
>> 
>>> It seems silly to check the index before calling `successor(of:)` when
>>> `successor(of:)` is going to immediately perform the same check again
>>> as a precondition.
>> 
>> Preconditions are not necessarily checked.  We don't promise to trap
>> every precondition violation.  We promise memory and type safety in the
>> absence of data races, and some precondition failures will trap in order
>> to ensure that.  Others will trap, where we think it is affordable, just
>> to provide a better programmer experience.
>
> I understand that, but many—perhaps most—clients of APIs like
> `successor(of:)` will need to perform a bounds check. 

Why do you say so?

> I think we would be better off if the check were implicit in the
> call. That would force all clients, or at least all clients which used
> the bounds-checking variants (which would be encouraged), to
> explicitly handle out-of-bounds conditions, in much the same way that
> `index(of:)` forces its clients to explicitly handle the possibility
> that a matching element might not exist, rather than returning
> `endIndex` (which would be easier).

I think we agree that the proposed index method that takes a limit
should return optional.  Dmitri's going to explain more in his response.

>>> 	collection.index(5, from: i)
>> 
>> I don't think this one reads clearly enough.
>
> "The index 5 from i" reads fine to me, but I guess that's a matter of opinion.
>
>>> 	collection.traveling(5, from: i)
>>> 	collection.striding(5, from: i)
>>> 	collection.advancing(i, by: 5)
>> 
>> None of the “ing” names work, IMO because that suffix suggests you're
>> returning a modified version of the receiver.
>
> Huh, that clarifies something. How about the non-`ing` variants?
>
> 	collection.travel(5, from: i)
> 	collection.stride(5, from: i)
> 	collection.advance(i, by: 5)

Active verb phrases are reserved for methods with side-effects according
to the API guidelines.

> I'd say `stride` might be an attractive nuisance in this form
> (although if Strideable's public face becomes `Self.striding(by:)`,
> only to Swift 2 users) but the others look fine to me.

I'm going to leave the rest of this for Dmitri, at least for the time
being.
-- 
Dave