Mixfix operators were a possibility sketched out in a recent proposal draft on operators by Jonathan Shapiro. That would enable custom syntax like you show here. Not sure if a revision of that draft is still in the works.
On Mon, Dec 19, 2016 at 22:37 Daniel Leping via swift-evolution < [email protected]> wrote: > 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 < > [email protected]> 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 < > [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]> 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]> 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]> 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]> wrote: > > > >> > > > >> > > > >> > > > >> Sent from my iPhone > > > >> > > > >>> On Dec 17, 2016, at 13:20, David Sweeris <[email protected]> wrote: > > > >>> > > > >>> > > > >>> > > > >>> Sent from my iPhone > > > >>> > > > >>>> On Dec 17, 2016, at 13:12, Micah Hainline via swift-evolution < > [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 > > > _______________________________________________ > > swift-evolution mailing list > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > > swift-evolution mailing list > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
