I believe regex was one of the topics that the core team proposed was a possibility for phase 2. I too am eager to hear what they have in mind. On Mon, Dec 19, 2016 at 23:02 Erica Sadun <er...@ericasadun.com> wrote:
> 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 <jh...@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@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@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@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@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 <daveswee...@mac.com> wrote: > >> > >> > >> > >> Sent from my iPhone > >> > >>> On Dec 17, 2016, at 13:20, David Sweeris <daveswee...@mac.com> wrote: > >>> > >>> > >>> > >>> Sent from my iPhone > >>> > >>>> On Dec 17, 2016, at 13:12, Micah Hainline via swift-evolution < > swift-evolution@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
