[swift-evolution] Strings in Swift 4

[Chris Lattner]

On Jan 26, 2017, at 11:15 AM, Dave Abrahams <dabrahams at apple.com> wrote:
>>>> You should instead be able to directly bind subexpressions into local
>>>> variables.  For example if you were trying to match something like
>>>> “42: Chris”, you should be able to use straw man syntax like this:
>>>> 
>>>>  case /(let id: \d+): (let name: \w+)/: print(id); print(name)
>>> 
>>> This is a good start, but inadequate for handling the kind of recursive
>>> grammars to which you want to generalize regexes, because you have to
>>> bind the same variable multiple times—often re-entrantly—during the same
>>> match.  Actually the Kleene star (*) already has this basic problem,
>>> without the re-entrancy, but if you want to build real parsers, you need
>>> to do more than simply capture the last substring matched by each group.
>> 
>> Please specify some more details about what the problem is, because
>> I’m not seeing it.  Lots of existing regex implementations work with
>> "(…)*” patterns by binding to the last value.  From my perspective,
>> this is pragmatic, useful, and proven.  What is your specific concern?
> 
> My specific concern is that merely capturing the last match is
> inadequate to many real parsing jobs.

Sure, depending on how the grammar is defined, the compiler will know when multiple matches are possible.  If multiple matches are possible, it is straight-forward to bind them into an array of results instead of a single scalar result.
 

>>>> Unless we were willing to dramatically expand how patterns work, this
>>>> requires baking support into the language.
>>> 
>>> I don't understand the "Unless" part of that sentence.  It seems obvious
>>> that no expansion of how patterns work could make the above work without
>>> language changes.
>> 
>> I’m not a believer in this approach, but someone could argue that we
>> should allow arbitrary user-defined syntactic expansion of the pattern
>> grammar, similar to how we allow syntactic expansion of the expression
>> grammar through operator definitions.  This is what I meant by
>> “dramatically expanding” how patterns work.
> 
> Oh, I see what you mean.  You need to bake *something* into the
> language.  That thing could either be regex support or it could be
> something more general, like a macro system that allowed beautiful regex
> support to be built in a library.  Well, I'd love to have the latter,
> but wouldn't be willing to sacrifice much quality-of-user-experience
> with in order to get it.  It would have to be roughly indistinguishable
> from the end-user's point-of-view.

Right.  The standard approach we take in Swift has been to start with something baked into the language, then generalize it out to the stdlib over time if there is a reason to.  I’d love to see the various magic around Optional be accessible to other types, for example.

-Chris