<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 31, 2015, at 7:46 PM, Susan Cheng <<a href="mailto:susan.doggie@gmail.com" class="">susan.doggie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">How GeneratorType confirm to Equatable??</div></div></div></blockquote><div><br class=""></div>I don’t understand the question. In the code I posted there’s a working example of how a GeneratorType model can conform to Equatable..</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">struct Fib : SequenceType {</div><div class=""> </div><div class=""> var a: Int</div><div class=""> var b: Int</div><div class=""> </div><div class=""> var limit: Int</div><div class=""> </div><div class=""> func generate() -> FibGenerator {</div><div class=""> return Generator(a: a, b: b, limit: limit)</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div><div class="">let c = Multipass(Fib(a: 1, b: -1, limit: 10))</div><div class=""><br class=""></div><div class="">-Susan</div><div class=""><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">2016-01-01 11:17 GMT+08:00 Dave Abrahams <span dir="ltr" class=""><<a href="mailto:dabrahams@apple.com" target="_blank" class="">dabrahams@apple.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">FWIW, Indexable is an implementation artifact that will go away when Swift’s generics system is improved.<br class="">
<br class="">
But if your real objection is that you have to come up with an Index and a subscripting operator, I can understand that. Part of the reason for this is our reluctance to create any distinct protocols with identical syntactic requirements <<a href="http://news.gmane.org/find-root.php?message_id=2A3E0C76-1C88-4752-8A70-AA64BB14223A@apple.com" rel="noreferrer" target="_blank" class="">http://news.gmane.org/find-root.php?message_id=2A3E0C76-1C88-4752-8A70-AA64BB14223A@apple.com</a>>. To justify having a separate multi-pass sequence protocol, there would have to be a significant/important class of multi-pass sequences for which CollectionType was unimplementable without serious costs.<br class="">
<br class="">
In principle there’s a way to ease the pain of creating CollectionType conformances for multipass SequenceTypes…if only it didn’t crash the compiler <<a href="https://bugs.swift.org/browse/SR-427" rel="noreferrer" target="_blank" class="">https://bugs.swift.org/browse/SR-427</a>> ;-). Here’s a variation that uses a generic adapter instead of a protocol conformance declaration:<br class="">
<br class="">
/// A `CollectionType` containing the same elements as `Base`, without storing them.<br class="">
///<br class="">
/// - Requires: `Base` supports multiple passes (traversing it does not<br class="">
/// consume the sequence), and `Base.Generator` has value semantics<br class="">
public struct Multipass<Base: SequenceType where Base.Generator: Equatable> : CollectionType {<br class="">
public var startIndex: MultipassIndex<Base> {<br class="">
var g = _base.generate()<br class="">
return MultipassIndex(buffer: g.next(), generator: g)<br class="">
}<br class="">
<br class="">
public var endIndex: MultipassIndex<Base> {<br class="">
return MultipassIndex(buffer: nil, generator: _base.generate())<br class="">
}<br class="">
<br class="">
public subscript(position: MultipassIndex<Base>) -> Base.Generator.Element {<br class="">
return position.buffer!<br class="">
}<br class="">
<br class="">
public init(_ base: Base) {<br class="">
_base = base<br class="">
}<br class="">
<br class="">
var _base: Base<br class="">
}<br class="">
<br class="">
// Note: Requires T.Generator has value semantics<br class="">
public struct MultipassIndex<T: SequenceType where T.Generator: Equatable> : ForwardIndexType {<br class="">
public func successor() -> MultipassIndex {<br class="">
var r = self<br class="">
r.buffer = r.generator.next()<br class="">
return r<br class="">
}<br class="">
var buffer: T.Generator.Element?<br class="">
var generator: T.Generator<br class="">
}<br class="">
<br class="">
public func == <T>(x: MultipassIndex<T>, y: MultipassIndex<T>) -> Bool {<br class="">
return x.buffer == nil && y.buffer == nil || x.generator == y.generator<br class="">
}<br class="">
<br class="">
//===--- An example fibonacci sequence ------------------------------------===//<br class="">
struct FibGenerator : GeneratorType {<br class="">
mutating func next() -> Int? {<br class="">
let c = a + b<br class="">
a = b<br class="">
b = c<br class="">
return a < limit ? a : nil<br class="">
}<br class="">
var a, b, limit: Int<br class="">
}<br class="">
<br class="">
<br class="">
struct Fib : SequenceType {<br class="">
var limit = 1000<br class="">
<br class="">
func generate() -> FibGenerator {<br class="">
return Generator(a: 0, b: 1, limit: limit)<br class="">
}<br class="">
}<br class="">
<br class="">
//===--- Adapt Fib for use with Multipass ---------------------------------===//<br class="">
extension FibGenerator : Equatable {}<br class="">
func == (x: Fib.Generator, y: Fib.Generator) -> Bool {<br class="">
return x.a == y.a<br class="">
}<br class="">
<br class="">
//===--- Demonstration ----------------------------------------------------===//<br class="">
let c = Multipass(Fib())<br class="">
print(c.first)<br class="">
print(c.count)<br class="">
print(c.lazy.map { $0 + 1 })<br class="">
</blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""><div class="">
-Dave
</div>
<br class=""></body></html>