> On Dec 27, 2016, at 11:46 AM, David Sweeris <daveswee...@mac.com> wrote: > >> >> On Dec 22, 2016, at 11:39 PM, Jonathan Hull <jh...@gbis.com >> <mailto:jh...@gbis.com>> wrote: >> >> >>> On Dec 20, 2016, at 12:29 PM, David Sweeris <daveswee...@mac.com >>> <mailto:daveswee...@mac.com>> wrote: >>> >>>> >>>> On Dec 20, 2016, at 2:11 AM, Jonathan Hull via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> Yes, I agree. I am excited to see what happens in phase 2. >>>> >>>> What I am suggesting here is slightly different. Basically being able to >>>> use RegEx (with capture groups) as a shorthand for a type composed of base >>>> literals. For example: (StringLiteral, [IntegerLiteral]). Named capture >>>> groups could even map to a dictionary literal. I am using “RegEx goes >>>> Here” to represent RegEx in the examples below, but hopefully it will get >>>> it’s own literal type in Xcode (Imagine that replacing it here). >>>> >>>> func foo( _ param: “RegExGoesHere”) {…} //Definition uses a RegEx where >>>> the type would normally be >>>> foo(“my parseable string") //Calling with a string literal >>>> >>>> In this case, ‘param’ takes a string literal when called but the compiler >>>> converts it to a tuple of literals based on the regEx supplied and passes >>>> that tuple the function. The type/structure of the tuple is defined by the >>>> capture groups in the RegEx >>>> >>>> The parameter above would only allow string literals to be passed in, and >>>> would give a compiler error if you tried to pass a variable or if the >>>> string didn’t conform to the supplied RegEx. To allow passing String >>>> variables you would have to add either ‘?’ or ‘!’ after the RegEx >>>> definition to handle the case where the value doesn’t conform. >>>> >>>> func foo( _ param: “RegExGoesHere”?) {…} //‘param' is nil if RegEx fails >>>> foo(myStringVar) //Calling >>>> >>>> func bar( _ param: “RegExGoesHere”!) {…} //fatal error if RegEx fails >>>> >>>> When a variable is passed, the RegEx is performed at runtime instead of >>>> compile time. >>>> >>>> Once you have this, the syntax to add new literal types/initializers falls >>>> out virtually for free. >>> >>> Is “RegExGoesHere” where the regex pattern goes, or where the string you’re >>> trying to match goes? If it’s the latter, where does the pattern go? If >>> it’s the former, where does the string you’re trying to match go? >> >> “RegExGoesHere” is where the pattern goes (instead of the type). The string >> you are trying to match gets passed in as the parameter (e.g. “my parseable >> string”). > Ah, ok, I think I understand what you’re saying now... You’re suggesting that > instead of defining a custom type that conforms to “RegExLiteral” (or some > other mechanism) and using that as the parameter’s type, you put your regex > pattern as the type directly?
Yes. It is admittedly an advanced feature, but I think it would be a useful one. Thanks, Jon
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
