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.
-- E p.s. For those that missed it: * earlier discussion: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160704/023966.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160704/023966.html> * draft work: https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c <https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c> > On Dec 18, 2016, at 3:52 PM, Xiaodi Wu <[email protected]> wrote: > > That's a fair point. I suppose we could have, in the same way as file > literals, > > ``` > #urlLiteral(resourceName: "http://example.com <http://example.com/>") > ``` > > which in an IDE would be automatically generated when someone drops a link > and might be rendered as a hyperlink, blue underline and all. > > > On Sun, Dec 18, 2016 at 16:17 Erica Sadun <[email protected] > <mailto:[email protected]>> wrote: > 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. > > -- E > > >> On Dec 17, 2016, at 10:18 PM, Xiaodi Wu via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> 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. >> >> On Sat, Dec 17, 2016 at 21:46 Step C via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> Probably worth pointing out that this topic seems entirely additive. Which >> means it would be at least a phase 2 proposal, if not later. >> >> >> >> >> >> > On Dec 17, 2016, at 4:44 PM, Micah Hainline via swift-evolution >> > <[email protected] <mailto:[email protected]>> wrote: >> >> >> > >> >> >> > 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. >> >> >> > >> >> >> >> On Dec 17, 2016, at 3:27 PM, David Sweeris <[email protected] >> >> <mailto:[email protected]>> wrote: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Sent from my iPhone >> >> >> >> >> >> >> >>> On Dec 17, 2016, at 13:20, David Sweeris <[email protected] >> >>> <mailto:[email protected]>> wrote: >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> Sent from my iPhone >> >> >> >>> >> >> >> >>>> On Dec 17, 2016, at 13:12, Micah Hainline via swift-evolution >> >>>> <[email protected] <mailto:[email protected]>> wrote: >> >> >> >>>> >> >> >> >>>> I'd love a fleshed out elegant example for URL that shows what a >> >>>> complete implementation of that special init method would look like. >> >> >> >>> >> >> >> >>> I can't do it now, but I'll try post one before tomorrow that shows how >> >>> I'd envision it working. >> >> >> >> >> >> >> >> 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. >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
