[swift-evolution] [Review] Constraining AnySequence.init
Kevin Ballard
kevin at sb.org
Fri Dec 18 17:13:54 CST 2015
*# What is your evaluation of the proposal?*
Overall it looks good. I haven't looked at the implementation of
AnySequence before, but it sound fairly reasonable.
A couple of minor nits:
1. The proposal motivation says
> At the moment AnyCollection does not delegate calls to SequenceType
> protocol methods to the underlying base sequence
Presumably that should say AnySequence instead of AnyCollection, since
the rest of the proposal talks about AnySequence?
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).
Given that, I'm inclined to say that we should of course go ahead and
have this == constraint here because that's the only way to satisfy the
requirement today, but just to note that if SequenceType can learn to
express this requirement directly the == constraint will go away as it's
perfectly fine then for subsequences of subsequences to be different
sequence types.
*# Is the problem being addressed significant enough to warrant a change
to Swift?*
Yeah. It's a fairly minor change in the scheme of things (should affect
very little code, if any), and it fixes a surprising hole in
AnySequence.
*# Does this proposal fit well with the feel and direction of Swift?*
Yes.
*# If you have you used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?*
Not applicable.
*# How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?*
A reasonably brief reading.
-Kevin Ballard
On Fri, Dec 18, 2015, at 09:59 AM, Douglas Gregor via swift-evolution wrote:
> Yikes, thank you! I have no idea how I managed that. Will re-send...
>
> - Doug
>
>> On Dec 18, 2015, at 9:58 AM, Félix Cloutier
>> <felixcca at yahoo.ca> wrote:
>>
>> The URL is right
>> (https://github.com/apple/swift-evolution/blob/master/proposals/0014-constrained-AnySequence.md)
>> , but the link points to a different proposal
>> (https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md)
>> . Copy-paste it to access the review.
>>
>>> Le 18 déc. 2015 à 12:51:57, Douglas Gregor via swift-evolution <swift-
>>> evolution at swift.org> a écrit :
>>>
>>> Hello Swift community,
>>>
>>> The review of “Constraining AnySequence.init” begins now and runs
>>> through Monday, December 21st, 2015. The proposal is available here:
>>>
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0014-constrained-AnySequence.md[1]
>>>
>>> Reviews are an important part of the Swift evolution process. All
>>> reviews should be sent to the swift-evolution mailing list at
>>>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> or, if you would like to keep your feedback private, directly to the
>>> review manager.
>>>
>>> What goes into a review?
>>>
>>> The goal of the review process is to improve the proposal under
>>> review through constructive criticism and, eventually, determine the
>>> direction of Swift. When writing your review, here are some
>>> questions you might want to answer in your review:
>>>
>>> * What is your evaluation of the proposal? * Is the problem being
>>> addressed significant enough to warrant a change to Swift? * Does
>>> this proposal fit well with the feel and direction of Swift? * If
>>> you have you used other languages or libraries with a similar
>>> feature, how do you feel that this proposal compares to those? * How
>>> much effort did you put into your review? A glance, a quick reading,
>>> or an in-depth study?
>>>
>>> More information about the Swift evolution process is available at
>>>
>>> https://github.com/apple/swift-evolution/blob/master/process.md
>>>
>>> Cheers, Doug Gregor Review Manager
>>>
>>> _______________________________________________
>>> swift-evolution mailing list swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _________________________________________________
> swift-evolution mailing list swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
Links:
1. https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/d6bdc8b9/attachment.html>
More information about the swift-evolution
mailing list