on Thu May 11 2017, Brent Royal-Gordon <swift-evolution@swift.org> wrote:
>> On May 11, 2017, at 2:39 PM, John McCall <rjmcc...@apple.com> wrote: >> What is your evaluation of the proposal? > These changes all look like improvements to me. (But I would say that, since > I recommended a couple > of them in the original review.) > > I notice that `Unicode.ParseResult`'s cases have lost their > `resumptionPoint`s. Is the intent that the fully-baked versions of the > higher-level APIs will pass these out in some other way? Sort of. The latest updates have a “length” in the error case and a “payload.count” in the valid case, which should give you the information you need to derive a new index. The problem we had with vending Index resumption points was that it penalized use with Sequences, which don't have indices. Even though parsing/decoding Sequences that aren't also Collections is probably a marginal use-case, that pattern was wound into the code paths of our existing implementations and our microbenchmarks have been tuned such that they detect any degradation of performance in that use-case. > If so, is there a possibility that `Unicode.ParseResult` will not be > adequate for those types, and it should be given a more specific name > like `Unicode.ScalarParseResult`? It's actually a very generally-useful parse result type AFAICT; we just stuck it in the Unicode namespace to avoid being presumptuous about what would be needed for other applications. I'm betting the same exact structure will work for general pattern matching, for example. -- -Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
