<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 20, 2016, at 8:28 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><blockquote type="cite" class="">On Tue, Dec 20, 2016 at 4:11 AM, Jonathan Hull <span dir="ltr" class=""><<a href="mailto:jhull@gbis.com" target="_blank" class="">jhull@gbis.com</a>></span> wrote:<br class=""></blockquote></div></div></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><br class=""></blockquote></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><blockquote type="cite" class=""><div class="gmail_extra"><div class="gmail_quote">Yes, I agree. I am excited to see what happens in phase 2.<br class=""><br class="">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).<br class=""><br class=""><span class="gmail-m_6935110629560369764Apple-tab-span" style="white-space: pre-wrap;"> </span>func foo( _ param: “RegExGoesHere”) {…} //Definition uses a RegEx where the type would normally be<br class=""><span class="gmail-m_6935110629560369764Apple-tab-span" style="white-space: pre-wrap;"> </span>foo(“my parseable string") //Calling with a string literal<br class=""><br class="">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<br class=""><br class="">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.<br class=""><br class=""><span class="gmail-m_6935110629560369764Apple-tab-span" style="white-space: pre-wrap;"> </span>func foo( _ param: “RegExGoesHere”?) {…} //‘param' is nil if RegEx fails<br class=""><span class="gmail-m_6935110629560369764Apple-tab-span" style="white-space: pre-wrap;"> </span>foo(myStringVar) //Calling<br class=""><br class=""><span class="gmail-m_6935110629560369764Apple-tab-span" style="white-space: pre-wrap;"> </span>func bar( _ param: “RegExGoesHere”!) {…} //fatal error if RegEx fails<br class=""><br class=""><div style="word-wrap:break-word" class=""><div class="">When a variable is passed, the RegEx is performed at runtime instead of compile time.</div></div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">Once better regex support comes to Swift, I'm sure there will be an ExpressibleByRegexLiteral.</div></div></div></div></div></blockquote></div><br class=""><div class="">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.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">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.</div></div></div></div></blockquote></div><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div></div></div></div></div><div class="">Does anyone have any issues with the requirements I posted earlier in the thread (<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161212/029497.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161212/029497.html</a>)? 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.</div><div class=""><br class=""></div><div class="">- Dave Sweeris</div><div class=""><br class=""></div><div class="">*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 <i class="">very</i> 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.</div></body></html>