Sent from my iPhone > On 3 May 2017, at 02:05, Howard Lovatt via swift-evolution > <[email protected]> wrote: > > My experience with languages that have generalised existential is that they > are superior in many circumstances; not just for collections, e.g. I gave the > example of the comparison protocol.
I think generalised existential is where we want to get to, is it not? > I don't think methods called on a returned generalised existential have to be > called via a Vtable. If the return type is Self<T> then the compiler can > eliminate the Vtable for selfs that are value types. For selfs that are > classes it would still have to use a Vtable though, because classes always > use Vtables! In most cases the return type will be Self<T> and in most cases > the Self will be a value type, so I would argue that in most cases a Vtable > won't be used. > > -- Howard. > >> On 2 May 2017, at 8:57 pm, Anders Ha <[email protected]> wrote: >> >> I would like to add that generalized existential is not really a better >> solution than letting the collection optionally and statically supply one. >> It consequentially forces all calls to the filtered collections >> virtual/dynamic. >> >> Higher kinded type would ideally help, but we all know it is not coming >> anytime soon, or perhaps ever. >> >> Regards >> Anders >> >>> On 2 May 2017, at 08:41, Xiaodi Wu via swift-evolution >>> <[email protected]> wrote: >>> >>> Howard, this is also mentioned in the generics manifesto under "Opening >>> existentials," and it's received plentiful discussion and will surely >>> receive more as these issues become addressed in future proposals. Let's >>> not divert the conversation here about map and filter. >>>> On Mon, May 1, 2017 at 19:36 Howard Lovatt <[email protected]> wrote: >>>> Yes, I know the change I suggested involves making generalised >>>> existentials. I am suggesting not making *any* changes until such effort >>>> is available. I understand that this would be after Swift 4. I think the >>>> wait would be worthwhile. >>>> >>>> As an aside: Currently one of the big issues with generalised existentials >>>> in Swift is with Self (which you can think of as a form of generic >>>> argument). Currently: >>>> >>>> protocol Equatable { >>>> static func ==(lhs: Self, rhs: Self) -> Bool >>>> ... >>>> } >>>> struct Int: Equatable { ... } >>>> let e1: Equatable = 1 >>>> let e2: Equatable = 2 >>>> if e1 == e2 { ... } // error: e1 and e2 don't necessarily have the >>>> same dynamic type >>>> >>>> I would replace this with: >>>> >>>> protocol Equatable<T> { // Use T instead of Self >>>> static func ==(lhs: T, rhs: T) -> Bool >>>> ... >>>> } >>>> struct Int: Equatable<Int> { ... } >>>> let e1: Equatable<Int> = 1 >>>> let e2: Equatable<Int> = 2 >>>> if e1 == e2 { ... } // No longer an error since they are both >>>> Equatable<Int> >>>> >>>> As an aside on the aside, even better: >>>> >>>> protocol Equatable<T = Self> { // T defaults to Self >>>> static func ==(lhs: T, rhs: T) -> Bool >>>> ... >>>> } >>>> struct Int: Equatable { ... } // T is Int, the default is Self >>>> let e1: Equatable = 1 // T is Int, the default is Self >>>> let e2: Equatable = 2 // T is Int, the default is Self >>>> if e1 == e2 { ... } // No longer an error since they are both >>>> Equatable<Int> >>>> >>>> Everything I am suggesting is done in other languages and from my personal >>>> experience works out better. >>>> >>>> >>>> -- Howard. >>>> >>>>> On 2 May 2017 at 09:53, Xiaodi Wu <[email protected]> wrote: >>>>> 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 >>>>> <[email protected]> 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 <[email protected]> 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 >>>>>>> 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 >>>>>>> [email protected] >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
