<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I personally would like something that lived outside the standard library and outside the immediate compiler. I don't think the color, file, and image literals that exist really should be part of core Swift. But I also don't think they should be Foundation either. I also would prefer something extensible (like customizable attributes) but that had a bar of community support to be added (CoreLiteral). :)</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Dec 18, 2016, at 6:56 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">With the passage of time, I continue to believe that literals in Swift are fundamentally valuable because they can, er, literally (or immediately/WYSIWYG-ly?) show in code something that must otherwise be interpreted by the human reader and then visualized in the mind's eye, and they allow users to input these things in a more natural way than text. (For instance, a color swatch as opposed to RGB numerals, a picture as opposed to a file path.)<br class=""><br class="">There is no limiting principle to your proposal about 'universal typeless concepts'; essentially all of Foundation is widely useful (foundational, if you like, or universal), and since each of these useful classes might be implemented by another library in a different way, one might wish for all of these classes to be initializable with a 'typeless' literal. Taken to its logical conclusion we circle back to a way of evaluating initialization of any arbitrary class in Foundation or any competing library at compile time. In fact, for many of the literals you propose, with some minor changes in syntax the result would be indistinguishable from the 'constexpr' proposal discussed above, and I think the latter would be the more holistic treatment that permits end users to use the feature for their own types as well.<br class=""><br class="">What I think you've convinced me of is that--regardless of other compile-time error-checking facilities--URLs would benefit from the same treatment as files. Indeed, one thing an IDE could do with a URL literal is to show the favicon, for instance, for a web page. This would immediately show a hint to the writer or reader of the code something more than whether or not their URL is malformed, but also whether at the time of writing it points to the intended endpoint.<br class=""><br class="">But that's quite enough from me for now--I'll be quiet and let others chime in on the subject.<br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Sun, Dec 18, 2016 at 17:59 Erica Sadun <<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg">Earlier in this thread, I pasted in a draft I discussed on-list (from July 10) about extending literals to include other "universal" typeless concepts including fonts, dates, points, etc but I should have spent a moment discussing why I had dropped that link. <div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-- E</div><div class="gmail_msg">p.s. For those that missed it: </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">* earlier discussion: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160704/023966.html" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160704/023966.html</a></div><div class="gmail_msg">* draft work: <a href="https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c" class="gmail_msg" target="_blank">https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c</a></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Dec 18, 2016, at 3:52 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="gmail_msg m_4089221271244330813Apple-interchange-newline"><div class="gmail_msg"><div class="gmail_msg">That's a fair point. I suppose we could have, in the same way as file literals,</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">```</div><div class="gmail_msg">#urlLiteral(resourceName: "<a href="http://example.com/" class="gmail_msg" target="_blank">http://example.com</a>")</div><div class="gmail_msg">```</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">which in an IDE would be automatically generated when someone drops a link and might be rendered as a hyperlink, blue underline and all.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">On Sun, Dec 18, 2016 at 16:17 Erica Sadun <<a href="mailto:erica@ericasadun.com" class="gmail_msg" target="_blank">erica@ericasadun.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">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 class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-- E</div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Dec 17, 2016, at 10:18 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="gmail_msg m_4089221271244330813m_1578985084152999226Apple-interchange-newline"><div class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">On Sat, Dec 17, 2016 at 21:46 Step C via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc 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_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">> On Dec 17, 2016, at 4:44 PM, Micah Hainline via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_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_msg"><br class="gmail_msg"><br class="gmail_msg">><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> On Dec 17, 2016, at 3:27 PM, David Sweeris <<a href="mailto:davesweeris@mac.com" class="gmail_msg" target="_blank">davesweeris@mac.com</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> Sent from my iPhone<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>>> On Dec 17, 2016, at 13:20, David Sweeris <<a href="mailto:davesweeris@mac.com" class="gmail_msg" target="_blank">davesweeris@mac.com</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>>><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>>><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>>><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>>> Sent from my iPhone<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>>><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>>>> On Dec 17, 2016, at 13:12, Micah Hainline via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>>>><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_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_msg"><br class="gmail_msg"><br class="gmail_msg">>>><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_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_msg"><br class="gmail_msg"><br class="gmail_msg">>><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_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_msg"></blockquote></div></div></blockquote></div><br class="gmail_msg"></div></div></div></div></blockquote></div></div>
</div></blockquote></div><br class="gmail_msg"></div></div></div></blockquote></div>
</div></blockquote></div><br class=""></body></html>