[swift-evolution] protocol can only be used as a generic constraint because it has Self or associated type requirements
Joe Groff
jgroff at apple.com
Mon Dec 14 12:32:33 CST 2015
> On Dec 14, 2015, at 7:40 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>
>
>> On Dec 14, 2015, at 6:23 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>> It is definitely possible to solve this problem for associated types by binding or constraining them. The ML module system has a feature that is roughly analogous to this.
>
> Keep in mind that a language feature like binding/constraining associated types is not a complete solution for real use-cases, so we would still need AnySequence<Element> in the library. Otherwise it would be SequenceType<Generator: SomeGenerator>, which binds a type that you don't actually want to expose.
With generic typealiases, you could say something like this:
typealias AnySequence<Element> =
protocol<SequenceType where Generator.Element == Element>
However, once we add 'where' requirements to protocols, it seems to me 'Element' really ought to be a direct requirement of SequenceType, like this:
protocol SequenceType {
typealias Element
typealias Generator: GeneratorType
where Element == Generator.Element
}
which would save generic code from having to splatter '.Generator.Element' everywhere, and make unspecialized code more efficient, since the type metadata for Element would be directly available from the SequenceType protocol witness table instead of needing an extra indirection through to its Generator's GeneratorType table.
-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151214/72f28003/attachment.html>
More information about the swift-evolution
mailing list