[swift-evolution] URL Literals

[Daniel Leping]

I was thinking about a possibility to extend the language itself with
custom literals. It should cover quite some stuff including URL, Regex, etc.

Just add an extended operator-ish syntax. Can be done with regular
expressions or similar.

//RegexLiteralDefinition
literal /(.*)/(.*)/ (regex:String, flags:String) -> RegexLiteralProtocol {
//code of construction here
}

//Use
let regex = /myregex/g/

//URLLiteralDefinition
literal u"(.*)" (url:String) -> URLLiteralProtocol {
//code of construction here
}

//use
let url = u"http://swift.org/"

This way we can add more literals later without compiler modifications.

If this gets any support I can create a draft of the spec for the feature.

On Tue, 20 Dec 2016 at 6:21 Jonathan Hull via swift-evolution <
swift-evolution at swift.org> 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> 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> 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> 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> 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> wrote:
>
>
> >>
>
>
> >>
>
>
> >>
>
>
> >> Sent from my iPhone
>
>
> >>
>
>
> >>> On Dec 17, 2016, at 13:20, David Sweeris <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> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
>
> swift-evolution mailing list
>
> 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/20161220/ce59a6fc/attachment.html>