<div dir="ltr">On Tue, Dec 20, 2016 at 4:11 AM, Jonathan Hull <span dir="ltr"><<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">Yes, I agree. I am excited to see what happens in phase 2.<div><br></div><div>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).</div><div><br></div><div><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</div><div><span class="gmail-m_6935110629560369764Apple-tab-span" style="white-space:pre-wrap"> </span>foo(“my parseable string") //Calling with a string literal</div><div><br></div><div>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</div><div><br></div><div>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.</div><div><br></div><div><span class="gmail-m_6935110629560369764Apple-tab-span" style="white-space:pre-wrap"> </span>func foo( _ param: “RegExGoesHere”?) {…} //‘param' is nil if RegEx fails</div><div><span class="gmail-m_6935110629560369764Apple-tab-span" style="white-space:pre-wrap"> </span>foo(myStringVar) //Calling</div><div><br></div><div><span class="gmail-m_6935110629560369764Apple-tab-span" style="white-space:pre-wrap"> </span>func bar( _ param: “RegExGoesHere”!) {…} //fatal error if RegEx fails</div><div><br></div><div>When a variable is passed, the RegEx is performed at runtime instead of compile time.</div></div></blockquote><div><br></div><div>Once better regex support comes to Swift, I'm sure there will be an ExpressibleByRegexLiteral. 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><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Once you have this, the syntax to add new literal types/initializers falls out virtually for free.</div><div><br></div><div>Thanks,</div><div>Jon</div><div><div class="gmail-h5"><div><br><div><blockquote type="cite"><div>On Dec 19, 2016, at 8:02 PM, Erica Sadun <<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.com</a>> wrote:</div><br class="gmail-m_6935110629560369764Apple-interchange-newline"><div><div style="word-wrap:break-word">Regex is another thing that appears on many platforms and has a standard way to express it.<div><br></div><div>-- E</div><div><br><div><blockquote type="cite"><div>On Dec 19, 2016, at 5:51 PM, Jonathan Hull <<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>> wrote:</div><br class="gmail-m_6935110629560369764Apple-interchange-newline"><div><div style="word-wrap:break-word">+1 to Erica’s literal extensions (and Xiaodi’s idea of showing Favicons in Xcode where possible)<div><br></div><div>Perhaps the easiest way to allow arbitrary literal extensions beyond those would be, in phase 2 when we add RegEx to the language, to take a RegEx defining the custom literal and have the compiler output a tuple of other literal types (including array literals for ‘*’, etc...) to the init method as a result of parsing it.</div><div><br></div><div>It would actually be interesting to have the parsing via RegEx into literals as a general feature for parameters, and then the init syntax would fall out basically for free...</div><div><br></div><div>Thanks,</div><div>Jon</div><div><br></div><div><br><div><blockquote type="cite"><div>On Dec 18, 2016, at 2:17 PM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="gmail-m_6935110629560369764Apple-interchange-newline"><div><div style="word-wrap:break-word"><div><div>I'd prefer to see a literal URL than a Foundation URL that is string-initializable. I don't see a URL literal as being in any way necessarily tightly coupled with a Foundation URL type. The point of a literal is that it is inherently typeless and checked at compile time. A color literal depending on context can be a UIColor or NSColor but that's not specified outside of the use context. The code is portable and cross platform.</div></div><div><div><br></div><div>-- E</div><div><br><div><br></div><div><div><blockquote type="cite"><div>On Dec 17, 2016, at 10:18 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="gmail-m_6935110629560369764Apple-interchange-newline"><div>With respect to URL specifically, that it's a Foundation type may change the timeline as well. Various improvements to the Foundation API (and URL in particular) have been proposed here, but if I remember correctly, the stated goal was first to have a complete Swift version of Foundation, preserving the existing API as exactly as possible with no additions or subtractions, and only then to consider Swifty evolution of the APIs. I don't think the first step is complete yet.<br><br><div class="gmail_quote"><div dir="ltr">On Sat, Dec 17, 2016 at 21:46 Step C via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Probably worth pointing out that this topic seems entirely additive. Which means it would be at least a phase 2 proposal, if not later.<br class="gmail-m_6935110629560369764gmail_msg">
<br class="gmail-m_6935110629560369764gmail_msg">
> On Dec 17, 2016, at 4:44 PM, Micah Hainline via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail-m_6935110629560369764gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail-m_6935110629560369764gmail_msg">
><br class="gmail-m_6935110629560369764gmail_msg">
> Yes, everyone who has what they feel like is a solid workable solution should write it up for URL and we can compare and pick holes in them all until we get something really solid.<br class="gmail-m_6935110629560369764gmail_msg">
><br class="gmail-m_6935110629560369764gmail_msg">
>> On Dec 17, 2016, at 3:27 PM, David Sweeris <<a href="mailto:davesweeris@mac.com" class="gmail-m_6935110629560369764gmail_msg" target="_blank">davesweeris@mac.com</a>> wrote:<br class="gmail-m_6935110629560369764gmail_msg">
>><br class="gmail-m_6935110629560369764gmail_msg">
>><br class="gmail-m_6935110629560369764gmail_msg">
>><br class="gmail-m_6935110629560369764gmail_msg">
>> Sent from my iPhone<br class="gmail-m_6935110629560369764gmail_msg">
>><br class="gmail-m_6935110629560369764gmail_msg">
>>> On Dec 17, 2016, at 13:20, David Sweeris <<a href="mailto:davesweeris@mac.com" class="gmail-m_6935110629560369764gmail_msg" target="_blank">davesweeris@mac.com</a>> wrote:<br class="gmail-m_6935110629560369764gmail_msg">
>>><br class="gmail-m_6935110629560369764gmail_msg">
>>><br class="gmail-m_6935110629560369764gmail_msg">
>>><br class="gmail-m_6935110629560369764gmail_msg">
>>> Sent from my iPhone<br class="gmail-m_6935110629560369764gmail_msg">
>>><br class="gmail-m_6935110629560369764gmail_msg">
>>>> On Dec 17, 2016, at 13:12, Micah Hainline via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail-m_6935110629560369764gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail-m_6935110629560369764gmail_msg">
>>>><br class="gmail-m_6935110629560369764gmail_msg">
>>>> I'd love a fleshed out elegant example for URL that shows what a complete implementation of that special init method would look like.<br class="gmail-m_6935110629560369764gmail_msg">
>>><br class="gmail-m_6935110629560369764gmail_msg">
>>> I can't do it now, but I'll try post one before tomorrow that shows how I'd envision it working.<br class="gmail-m_6935110629560369764gmail_msg">
>><br class="gmail-m_6935110629560369764gmail_msg">
>> Oh, and to be clear, I'm not trying to "claim" this or anything... if anyone else has ideas, please post them! The more the merrier.<br class="gmail-m_6935110629560369764gmail_msg"></blockquote></div></div></blockquote></div><br></div></div></div></div>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></div></div></blockquote></div><br></div></div>