[swift-evolution] [swift-evolution-announce] [Review] SE-0174: Change `filter` to return an associated type

[Xiaodi Wu]

Howard, take a look at the generics manifesto section on generic protocols:

https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md

It explains very nicely how what you're really asking for is not generic
protocols but generalized existentials. This would be nice to have, but
it's clearly not happening within the next month and it wouldn't change the
solution for filter, for which this proposal is the obvious fix.

On Mon, May 1, 2017 at 18:09 Howard Lovatt via swift-evolution <
swift-evolution at swift.org> wrote:

> review of SE-0174 "Change `filter` to return an associated type"
>
>
>    - What is your evaluation of the proposal?
>
> I think a change in this 'area' is valuable because currently always
> returning an array from collection operations is limiting. However I think
> this proposal feels like 'papering' over problems rather than fixing the
> root cause. I think it would be better to reject this and do two more
> adventurous proposals instead:
>
>   1. Allow protocols to be generic, instead of associated types, so that
> you can write Sequence<T>
>   2. Allow Self to accept a generic argument, so that you can write Self<T>
>
> With these to, admittedly much more major changes, you can then write:
>
>     protocol Sequence<T> {
>         func filter(_ isIncluded: (T) throws -> Bool) rethrows ->
> Sequence<T>
>         func map<M>(_ mapper: (T) throws -> M) rethrows -> Sequence<M>
>     }
>     extension RangeReplaceableCollection {
>         func filter(_ isIncluded: (T) throws -> Bool) rethrows -> Self<T>
>  {
>             var result = Self<T>()
>             for element in self {
>                 if try isIncluded(element) {
>                      result.append(element)
>                 }
>             }
>            return result
>         }
>         func map<M>(_ mapper: (T) throws -> M) rethrows -> Self<M> {
>             var result = Self<M>()
>             for element in self {
>                 try result.append(mapper(element))
>             }
>            return result
>         }
>     }
>
> Which I think both reads better and is more powerful since it allows map
> to be written also.
>
>
>    - Is the problem being addressed significant enough to warrant a
>    change to Swift?
>
> Yes, return an array is a real pain
>
>
>    - Does this proposal fit well with the feel and direction of Swift?
>
> Yes and no, really smacks of papering over other flaws. Might box Swift
> into a corner were other problems can't be fixed because the underlying,
> real, problems still remain.
>
>
>    - If you have used other languages or libraries with a similar
>    feature, how do you feel that this proposal compares to those?
>
> Virtually all other languages I have used, e.g. Java, Scala, use the
> solution I presented above.
>
>
>    - How much effort did you put into your review? A glance, a quick
>    reading, or an in-depth study?
>
> Have been bitten by this and have written my own collection hierarchy to
> overcome this limitation, and others, of the current library.
>
> -- Howard.
>
> On 29 Apr 2017, at 10:06 am, Douglas Gregor <dgregor at apple.com> wrote:
>
> Hello Swift community,
>
> The review of SE-0174 "Change `filter` to return an associated type"
> begins now and runs through May 3, 2017. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.md
>
> 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. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.md
>
> Reply text
>
> Other replies
>
> <https://github.com/apple/swift-evolution#what-goes-into-a-review-1>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 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
>
> Thank you,
>
> -Doug Gregor
>
> Review Manager
>
> _______________________________________________
> swift-evolution-announce mailing list
> swift-evolution-announce at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170501/6bf8d0a7/attachment.html>