[swift-evolution] [Swift4] Priorities and Sugar

[Daniel Leping]

Hey guys,

TL;DR; proposed solution in the second half.

actually, we are already doing something like this without modifying the
language itself here:
https://github.com/crossroadlabs/Regex/blob/swift2.x/Regex/String%2BRegex.swift

It's Scala style (.r notion). Works perfectly with switch keyword:

*switch letter {*

*    //note .r after the string literal of the pattern*

*    case "\\d".r: print("digit")*

*    case "[a-z]".r: print("letter")*

*    default: print("bizarre symbol")*

*}*

You can try it in release 0.8 (for Swift 2.x, Swift 3.0 release with this
feature is not issued yet).

What we really lack though is matching objects to tuples with *switch*.
Here is the explanation:

Let's say we have a match:

let match = "(\d*)(.*)".r.findFirst("123abc")

what I would love to do with it is the following:

*switch match {*

*case (_, "xyz"): print("end of alphabet")*

*case ("123", _): print("beginning of numerics")*

*default: print("I don't care")*

*}*

It would be possible if ~= operator was a bit more powerful and allow to
match against tuples (currently, it can't even without underscores). What I
would like to propose (will create an evolution proposal later if it's
something the core-team is willing to consider) is to:

1. Either extend ~= to allow to match tuples. Currently, I see it the
following way (an example):

*// you have to create an operator for each tuple size, any ideas on a
better solution?*

*func ~=<A, B>(match:Match, tuple:(A?, B?)) -> Bool*

Why optionals? Well, this way we could process _ substitutions.

2. Implement Scala-like apply/unapply. Good too, but option one sounds more
"Swiftish" to me personally.


Why is this cool? Well, this is not just about Regular Expressions, it's
rather overall language power and Regex is a nice example. I think there
will be a lot of examples, especially with the web apps. Some additional
ones I can think of right away is processing of URL or query params or
"parsing" of message object (i.e. in Actors or Queues).

Why making the match object to be an enum would not work? Well, first of
all there is some more additional info in it which I would like to keep
hidden for the user (i.e. full match, etc.) and not to push to match to.
This is not just one use case and in others it might become even more
important.

Hope it's clear and understandable (let me know if not and I'll bring it in
more details). Would this fit to Swift 3.x (no existing code impact) or to
Swift 4.x?

Best,

Daniel

On Sat, Jul 30, 2016 at 12:37 PM, Charlie Monroe via swift-evolution <
swift-evolution at swift.org> wrote:

> > Foundation already has NSRegularExpression. Do you mean that the
> > stdlib could potentially duplicate Foundation functionality?
>
> NSRegularExpression is not really easy to use for most common usecases
> (first match in string, etc.) + it lacks a lot of features e.g. Python has
> (named groups, etc.). I've personally never used NSRegularExpression and
> rather wrote an ObjC wrapper around re2 (https://github.com/google/re2/).
>
> I'd really like Swift's regex to be much more powerful and be able to
> match against it in a switch:
>
> switch someString {
> case /\d+:
>         ...
> case /w+:
>         ...
> ...
>
> Also, you can have compile-time check whether the expression is valid if
> regex is part of the language. But that's kind of getting too specific and
> away from the original discussion.
>
>
> > If so,
> > what are the implications for Foundation (and
> > swift-corelibs-foundation)? Does this also mean that other "stringy"
> > functionality could arrive in the stdlib, for example a Swifty JSON
> > serializer/deserializer?
> >
> > Best wishes,
> >
> > --
> > Ian Partridge
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160730/0445dac3/attachment.html>