[swift-evolution] Strings in Swift 4

[Dave Abrahams]

on Fri Jan 27 2017, Chris Lattner <sabre-AT-nondot.org> wrote:

> On Jan 25, 2017, at 7:27 AM, Chris Eidhof <chris at eidhof.nl> wrote:
>> I wonder if built-in grammars (that's what Perl calls them) would
>> work only for things that are backed by string literals, or if it's
>> worth the time/effort to make them work for other kind of data as
>> well. For example, what if you write a grammar to tokenize (yielding
>> some sequence of `Token`s), and then want to parse those `Token`s?
>> Or what if you want to parse other kinds of data? Or should we try
>> to make the 80% case work (only provide grammar/regex literals for
>> Strings) to avoid complexity?
>
> I don’t have a strong opinion on this matter.  I can definitely see
> the elegance of being able to pattern match non-string data with the
> regex features.  Certainly things like parsing fixed packet formats
> coming off a network seem like good candidates for this sort of thing.
>
> That said, it isn’t clear to me that this would be widely-used enough
> to be worth the complexity cost.  If it just drops into the existing
> model (e.g. the string model works on sequences of bytes, so this just
> falls out of it) then that would be great.  If it requires massive
> complexity for little gain, then probably not.  We can see when it
> comes time to actually design and build this functionality out and
> lazily evaluate the decision based on what we know then.

It's actually much simpler to do for ordinary collections than it is for
Strings, for which you want to optimize pattern matching based on
knowledge of string-specific properties such as encoding, normalization,
etc.  The Collection matching API is pretty straightforward
(https://github.com/apple/swift/blob/master/test/Prototypes/PatternMatching.swift#L32).
Extending it to be able to take advantage of auxilliary encoding
information is what's going to add complexity.

-- 
-Dave