I'm looking for a good starter project, so normally I would be interested
in taking this, but I'm not sure I can think of a good motivation for it.
UnsafePointer's advanceBy and distanceTo functions take care of pointer
arithmetic more safely than converting to int would, and the
debugDescription p
common to check the
> alignment of pointers so that initial elements can be processed until some
> suitable alignment is reached to use a faster implementation, or to verify
> that a fast algorithm can be used.
>
> On Dec 8, 2015, at 10:59 AM, Michael Buckley via swift-dev <
>
quot;sometimes a C API only lets you pass data as an
> Int (intptr_t) or as an UnsafeMutablePointer (void *), and you have the
> other kind of data". That said, it does seem to be sort of a niche use case.
>
> Jordan
>
> On Dec 8, 2015, at 7:59, Michael Buckley via swift-de
Hello,
I would like to fix rdar://20511834 , which is that the new skin tone and
multi-person grouping emoji introduced with iOS 8.3 and OS X 10.10.3 are
represented as multiple extended grapheme clusters by Swift.String, and I
have a few questions.
1. Is this something we want to fix at this tim
Thanks for the response, Dimitri. My comments inline below.
On Fri, Dec 18, 2015 at 3:29 AM, Dmitri Gribenko
wrote:
>
>
> One thing to do would be to check the Apple's ICU implementation, which (I
> think) implements some extra handling for UTR #51 (
> http://opensource.apple.com/release/os-x-101
After reading through the ICU sources, if I understand them correctly, ICU
uses the Aho–Corasick algorithm to determine grapheme breaks, word breaks
and line breaks, and then does some post-processing after matching using
the algorithm.
This allows ICU to solve the regional indicator problem by in
It actually appears that Swift already links against ICU. I'll see if I can
hook Swift up to ICU's grapheme separation code.
On Sun, Dec 20, 2015 at 10:41 PM, Michael Buckley
wrote:
> After reading through the ICU sources, if I understand them correctly, ICU
> uses the Aho–Corasick algorithm to
likely your changes caused something wrong with the
> offsets, so if the source text is fine it should be good to update the
> expected output.
> If the offsets changed without the source text changing, then we have an
> issue with the offsets.
>
> > On Apr 11, 2016, at 7:55 PM, Mi
