[swift-evolution] URL Literals

[David Sweeris]

> On Dec 20, 2016, at 8:28 AM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Tue, Dec 20, 2016 at 4:11 AM, Jonathan Hull <jhull at gbis.com <mailto:jhull at gbis.com>> 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 better regex support comes to Swift, I'm sure there will be an ExpressibleByRegexLiteral.

Yeah, once we get regex support, I’d push for an `ExpressibleByRegexLiteral` regardless of how the rest of this URL Literal proposal works out. I’m curious as whether that would be more flexible or less, compared to the “ExpressibleByValidated*Literal” idea. Especially WRT call-site syntax, since my understanding is that it’s much simpler to go back and rework architectural stuff later on if you can keep the call-site syntax the same.

> The missing piece, though, is to have a way to indicate that some pure function (or in this case, initializer) can be evaluated at compile time if possible. Once we have that, your desired solution falls out for free.


Does anyone have any issues with the requirements I posted earlier in the thread (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161212/029497.html)? AFAIK, I think it’s reasonably complete* for constant expressions. As a bonus (IMHO, anyway) adding `@constexpr` would lay the groundwork for adding `@pure` later on, both in terms of language precedent and probably with the complier-side work for validating that an expression really is what we claim it is, too.

- Dave Sweeris

*One could argue that allowing read-only access to files, while probably not in the “spirit” of constant expressions, probably wouldn’t break anything and could be very useful for changing the compiled code based on settings in a configuration file. I don’t have enough experience in the area to have a strong opinion on this particular point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161220/0a6a6f4f/attachment.html>