[swift-evolution] [Review] Constraining AnySequence.init

[Kevin Ballard]

Well actually...

LazyCollection right now has just this very behavior. The SubSequence of
a LazyCollection<T> is a LazyCollection<Slice<T>>. If you say
`[1,2,3].lazy.prefixUpTo(3).prefixUpTo(3)` you end up with a
LazyCollection<Slice<Slice<[Int]>>>. So the only way we can constrain
SubSequence this way is by also making it possible for LazyCollection to
"flatten" the slices.

-Kevin Ballard

On Fri, Dec 18, 2015, at 10:03 PM, Kevin Ballard wrote:
> Fair enough. I was thinking that it's better to err on the side of
> allowing flexibility, but there is something to be said for having
> slices of slices still be slices. My vague thought was that there
> might be some desire to have a slice be a type that wraps the thing
> being sliced, but I admit that I can't think offhand of any reason why
> a FooSlice<FooSlice<FooSlice<Foo>>> would be useful.
>
> -Kevin
>
> On Fri, Dec 18, 2015, at 08:51 PM, Dmitri Gribenko wrote:
>> Hi Kevin,
>>
>> Thank you for your feedback!
>>
>> On Fri, Dec 18, 2015 at 3:13 PM, Kevin Ballard via swift-evolution
>> <swift-evolution at swift.org> wrote:
>>> 2. One of the added constraints looks like
>>>
>>> S.SubSequence.SubSequence == S.SubSequence
>>>
>>> with a comment saying that ideally the set of constraints would
>>> apply to the SequenceType protocol but that's not currently
>>> possible. This makes sense for the other constraints (that
>>> SubSequence conforms to SequenceType and has the same element), but
>>> this particular constraint, that the subsequence type must have
>>> itself as its own subsequence, surprises me a little. I can see why
>>> it's needed here (because that's the only way you can guarantee that
>>> recursing through SubSequences always finds SequenceTypes with the
>>> right element), but ideally we wouldn't actually require it to be
>>> the _same_ sequence, just that it is some sequence with the same
>>> element type. If we ever change Swift such that these constraints
>>> can be expressed on the SequenceType definition itself, then
>>> presumably we'll be able to drop this == constraint entirely as the
>>> SequenceType protocol itself will ensure that its subsequence is a
>>> sequence of the same element type (which will satisfy the need to
>>> have it be true after arbitrary levels of recursion).
>>
>> The idea behind putting this constraint into the protocol was to make
>> it possible to write code that repeatedly slices a collection without
>> getting a ton of different types along the way:
>>
>> var myCollectionSlice = myCollection[myCollection.indices]
>> myCollectionSlice = myCollectionSlice.dropFirst()
>>
>> Also, we couldn't come up with an example of a sequence or a
>> collection that needs to have different SubSequence types on
>> different depth levels for efficiency or type safety reasons.  Given
>> that we think we aren't limiting expressivity with this constraint,
>> having a simpler model (the operation of slicing slices is closed in
>> the set of types) is better.
>>
>> I'd be happy to hear if you know some sequence or collection types
>> that would benefit from not having this constraint.
>>
>> 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>*/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/ecdd80b9/attachment.html>