[swift-evolution] [swift-evolution-announce] [Review] SE-0163 [2]: String Revision: Collection Conformance, C Interop, Transcoding

[Dave Abrahams]

on Thu May 11 2017, Brent Royal-Gordon <swift-evolution at swift.org> wrote:

>> On May 11, 2017, at 2:39 PM, John McCall <rjmccall at 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