Disappearing AnyGenerator/AnySequence/AnyCollection wrapper types


(Erica Sadun) #1

Joe wrote: "What changes would be necessary to the standard library to make the most of this feature? Some particular problems we'd like to solve are to eliminate the need for the AnyGenerator/AnySequence/AnyCollection wrapper types, and to provide a solution for heterogeneous equality, so that protocols can inherit Equatable and Hashable without forfeiting the ability to be used dynamically. See Brent Simmons' Swift diary posts at http://inessential.com/swiftdiary for an example of why the latter is important."

Any advice for what could be done now in preparation for any changes that might happen and an estimate of when these types might be on the chopping block? Not 3.0, right? But 4.0? What are good ways to work around this now using current (and presumably stable) constructs?

Thanks, -- E


(David Hart) #2

I’ve had a few discussions about that with Joe and Rob Rix, where I understood less than I’d like to admit :slight_smile: Joe recently said that the subject of type-erasure is probably not currently planned for Swift 3, but saying that:

@rob_rix @dhartbit Fixing cyclic assoc type references will give us the runtime support for those existentials, at least.
https://twitter.com/jckarter/status/675322278675001344

If that makes sense to you.

···

On 14 Dec 2015, at 23:24, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Joe wrote: "What changes would be necessary to the standard library to make the most of this feature? Some particular problems we'd like to solve are to eliminate the need for the AnyGenerator/AnySequence/AnyCollection wrapper types, and to provide a solution for heterogeneous equality, so that protocols can inherit Equatable and Hashable without forfeiting the ability to be used dynamically. See Brent Simmons' Swift diary posts at http://inessential.com/swiftdiary for an example of why the latter is important."

Any advice for what could be done now in preparation for any changes that might happen and an estimate of when these types might be on the chopping block? Not 3.0, right? But 4.0? What are good ways to work around this now using current (and presumably stable) constructs?

Thanks, -- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(TJ Usiyan) #3

I *think* that Joe is talking about when two protocols require mention of
each other. This forms an odd cycle in the type system right now when you
try to use it.

protocol SequenceType {
typealias Generator : GeneratorType
}

protocol GeneratorType {
typealias Sequence : SequenceType
}

···

On Mon, Dec 14, 2015 at 5:47 PM, David Hart via swift-evolution < swift-evolution@swift.org> wrote:

I’ve had a few discussions about that with Joe and Rob Rix, where I
understood less than I’d like to admit :slight_smile: Joe recently said that the
subject of type-erasure is probably not currently planned for Swift 3, but
saying that:

*@rob_rix @dhartbit Fixing cyclic assoc type references will give us the
runtime support for those existentials, at least.*
https://twitter.com/jckarter/status/675322278675001344

If that makes sense to you.

On 14 Dec 2015, at 23:24, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:

Joe wrote: "What changes would be necessary to the standard library to
make the most of this feature? Some particular problems we'd like to solve
are to eliminate the need for the AnyGenerator/AnySequence/AnyCollection
wrapper types, and to provide a solution for heterogeneous equality, so
that protocols can inherit Equatable and Hashable without forfeiting the
ability to be used dynamically. See Brent Simmons' Swift diary posts at
http://inessential.com/swiftdiary for an example of why the latter is
important."

Any advice for what could be done now in preparation for any changes that
might happen and an estimate of when these types might be on the chopping
block? Not 3.0, right? But 4.0? What are good ways to work around this now
using current (and presumably stable) constructs?

Thanks, -- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution