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). :)
-- E > On Dec 18, 2016, at 6:56 PM, Xiaodi Wu <[email protected]> wrote: > > 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.) > > 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. > > 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. > > But that's quite enough from me for now--I'll be quiet and let others chime > in on the subject. > > On Sun, Dec 18, 2016 at 17:59 Erica Sadun <[email protected] > <mailto:[email protected]>> wrote: > 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] >> <mailto:[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
