[swift-evolution] URL Literals

[Erica Sadun]

Regex is another thing that appears on many platforms and has a standard way to express it.

-- E

> On Dec 19, 2016, at 5:51 PM, Jonathan Hull <jhull at gbis.com> wrote:
> 
> +1 to Erica’s literal extensions (and Xiaodi’s idea of showing Favicons in Xcode where possible)
> 
> 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.
> 
> 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...
> 
> Thanks,
> Jon
> 
> 
>> On Dec 18, 2016, at 2:17 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <davesweeris at mac.com <mailto:davesweeris at mac.com>> wrote:
>>> >>
>>> >>
>>> >>
>>> >> Sent from my iPhone
>>> >>
>>> >>> On Dec 17, 2016, at 13:20, David Sweeris <davesweeris at mac.com <mailto:davesweeris at mac.com>> wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> Sent from my iPhone
>>> >>>
>>> >>>> On Dec 17, 2016, at 13:12, Micah Hainline via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161219/f9039f5b/attachment.html>