On Thu, Dec 29, 2016 at 3:18 PM, Micah Hainline <micah.hainl...@gmail.com> wrote:
> I think that's all doable. I'm not sure what delimiters would be the > best though, which is why I hadn't moved away from #url yet. I've been > thinking hard about the regex, which seems like an even stronger case > to make into a literal, and /abc/ works well for those, but even those > have some problems, as an empty regex (valid according to > NSRegularExpression) of // would parse also as a comment. True, but I doubt that's a common use case. JavaScript supports `/regex/` and I haven't heard of complaints re not supporting `//`. > For < and > > it could start getting confusing with overloaded operators. I think it > would work, but could be a little trickier than it seems like on first > blush. > Besides being a natural way of writing it, < and > have the advantage that resolving their different uses is already heavily tested (because generics use <>, and because the lexer understands merging artifacts like <<<<<< and >>>>>>). > It would be easier to lex if it were expressed like > #url<https://example.com>, but ease of lexing probably doesn't weigh > that heavily. If we wanted to do more than string, url, and regex we'd > start running out of delimiters fast though... > To me, that's a feature, not a bug. I'd argue that the language should provide first-class support for only a few, very important literals (like strings). Compile time validation for arbitrary types, as I've said before, should probably be solved in other, more holistic ways (such as some sort of constexpr-like feature). Another idea (taking from ruby a little) would be to have something > like %url{https://example.com} and %regex{my/regex} > > In ruby, their %r{} structure can take things other than {} as long as > they don't appear in the string (for instance %r@my/regex@ works too), > we could do something like that and have a pretty robust structure for > whatever literals we wanted going forward, and it should work for url > and regex, which are in the more immediate future. Of course, % could > just as easily be #. We had that before, essentially. Object literals (file, image, color) were spelled like this: [#Color(...)#]. They were removed with SE-0039. On Thu, Dec 29, 2016 at 12:37 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > Micah, > > > > I think I'm coming round to your line of thinking re URL literals. It'd > be > > nice to have them supported first-class, not like image literals (the > design > > for which is really geared towards playgrounds and is rather hacky, IMO), > > but like strings. In that scenario, Foundation URL would conform to > > ExpressibleByURLLiteral. URL could even be the default URLLiteralType > once > > Foundation is imported (just like String is the default > StringLiteralType). > > > > What'd be _really_ nice, though, is to solidify the first-class status of > > URL literals by their spelling: not `#urlLiteral(resourceName: > "blahblah")` > > or even `#url("blahblah")`, but just as you write `let str = "this is a > > string"` (and I'm sure we'll have `let regex = /foo/`), we should have > `let > > url = <https://google.com/>`. The compiler would ensure that what's > between > > the delimiters is a valid relative or absolute URL, and > `init(urlLiteral:)` > > will get a parsed tuple just as the official standard outlines, with > scheme, > > username, password, host, port, cannot-be-a-base-URL flag, path, query, > > fragment all ready to go. Looking through the lexer, it seems like this > > _should_ be possible and not inordinate amounts of work. Any thoughts > about > > this idea, since you're actively studying the lexer? > > > > Xiaodi > > > > > > On Wed, Dec 28, 2016 at 5:18 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > >> > >> PR #6503. Turned out to be trivial. > >> > >> On Wed, Dec 28, 2016 at 4:38 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > >>> > >>> Not yet, still building locally. My computer's slow. There's one > problem > >>> that's apparent though. Here's an existing test in the repo: > >>> > >>> ``` > >>> LiteralsTestSuite.test("image") { > >>> let image = #imageLiteral(resourceName: NSImageNameComputer) > >>> expectTrue(image.isValid) > >>> } > >>> ``` > >>> > >>> Unfortunately, although `NSImageNameComputer` is a constant, it's of > type > >>> `String`. And tweaking global Obj-C bridging rules so that `NSString * > >>> const` comes through as `StaticString` is just not gonna happen, > because of > >>> all the things you'd break. We'll lose this (kinda useful) use of > >>> #imageLiteral unless someone goes ahead and manually bridges the > >>> NSImageName* constants, which is acceptable, I suppose. That someone > would > >>> have to be the Foundation team, because Foundation APIs aren't really > >>> subject to Evolution. > >>> > >>> > >>> On Wed, Dec 28, 2016 at 4:29 PM, Micah Hainline > >>> <micah.hainl...@gmail.com> wrote: > >>>> > >>>> Do you have it checked in somewhere I can see it? > >>>> > >>>> On Wed, Dec 28, 2016 at 2:51 PM, Xiaodi Wu <xiaodi...@gmail.com> > wrote: > >>>> > I may be wrong, but I think I've fixed it. Will test and make sure. > >>>> > > >>>> > On Wed, Dec 28, 2016 at 3:22 PM, Xiaodi Wu <xiaodi...@gmail.com> > >>>> > wrote: > >>>> >> > >>>> >> Well, let's stop that :) > >>>> >> > >>>> >> > >>>> >> On Wed, Dec 28, 2016 at 3:21 PM, Micah Hainline > >>>> >> <micah.hainl...@gmail.com> > >>>> >> wrote: > >>>> >>> > >>>> >>> Yep, compiles, runs, no warnings or errors and the program > displays > >>>> >>> the expected results. > >>>> >>> > >>>> >>> On Wed, Dec 28, 2016 at 2:12 PM, Micah Hainline > >>>> >>> <micah.hainl...@gmail.com> wrote: > >>>> >>> > Good question. It certainly compiles, but I've stuck it in an > >>>> >>> > out-of-the-way spot, I'll need to create a test project to know > >>>> >>> > the > >>>> >>> > answer to that. Just FYI: https://bugs.swift.org/browse/SR-3504 > >>>> >>> > > >>>> >>> > > >>>> >>> > On Wed, Dec 28, 2016 at 2:11 PM, Xiaodi Wu <xiaodi...@gmail.com > > > >>>> >>> > wrote: > >>>> >>> >> Does it run? > >>>> >>> >> > >>>> >>> >> On Wed, Dec 28, 2016 at 3:10 PM, Micah Hainline > >>>> >>> >> <micah.hainl...@gmail.com> > >>>> >>> >> wrote: > >>>> >>> >>> > >>>> >>> >>> I'm doing it in a normal project rather than a playground. > >>>> >>> >>> > >>>> >>> >>> On Wed, Dec 28, 2016 at 1:50 PM, Xiaodi Wu < > xiaodi...@gmail.com> > >>>> >>> >>> wrote: > >>>> >>> >>> > Offlist-- > >>>> >>> >>> > > >>>> >>> >>> > In a playground, I get a runtime error when I move the > string > >>>> >>> >>> > into > >>>> >>> >>> > a > >>>> >>> >>> > variable and write `#fileLiteral(resourceName: "\(myVar)")`. > >>>> >>> >>> > Could > >>>> >>> >>> > be > >>>> >>> >>> > doing > >>>> >>> >>> > it wrong though. > >>>> >>> >>> > > >>>> >>> >>> > I'll submit a PR to document that users should not use the > >>>> >>> >>> > technically > >>>> >>> >>> > public APIs for literals. > >>>> >>> >>> > > >>>> >>> >>> > > >>>> >>> >>> > On Wed, Dec 28, 2016 at 2:44 PM, Micah Hainline via > >>>> >>> >>> > swift-evolution > >>>> >>> >>> > <swift-evolution@swift.org> wrote: > >>>> >>> >>> >> > >>>> >>> >>> >> I think the way it's set up it probably WOULD run, but it > >>>> >>> >>> >> should > >>>> >>> >>> >> still > >>>> >>> >>> >> probably be a compile error. I like that we have the > concept > >>>> >>> >>> >> of > >>>> >>> >>> >> static-string-literal in the language definition, but I'm > >>>> >>> >>> >> having a > >>>> >>> >>> >> bit > >>>> >>> >>> >> of a hard time tracking it through the compiler. Of course, > >>>> >>> >>> >> these > >>>> >>> >>> >> are > >>>> >>> >>> >> problems probably not right for this list, so I'll take > them > >>>> >>> >>> >> into > >>>> >>> >>> >> a > >>>> >>> >>> >> bug instead. > >>>> >>> >>> >> > >>>> >>> >>> >> On Wed, Dec 28, 2016 at 1:36 PM, Xiaodi Wu > >>>> >>> >>> >> <xiaodi...@gmail.com> > >>>> > >>>> >>> >>> >> wrote: > >>>> >>> >>> >> > On Wed, Dec 28, 2016 at 2:29 PM, Micah Hainline via > >>>> >>> >>> >> > swift-evolution > >>>> >>> >>> >> > <swift-evolution@swift.org> wrote: > >>>> >>> >>> >> >> > >>>> >>> >>> >> >> > SE-0039 says that resourceName should be a > >>>> >>> >>> >> >> > static-string-literal > >>>> >>> >>> >> >> > >>>> >>> >>> >> >> It compiles just fine for me in my project. My next > >>>> >>> >>> >> >> question > >>>> >>> >>> >> >> was > >>>> >>> >>> >> >> going > >>>> >>> >>> >> >> to be do we actually need a change in the language spec, > >>>> >>> >>> >> >> or can > >>>> >>> >>> >> >> we > >>>> >>> >>> >> >> call fixing that a bug, I think you're answering my > >>>> >>> >>> >> >> question > >>>> >>> >>> >> >> for me > >>>> >>> >>> >> >> before I even had to ask it! > >>>> >>> >>> >> > > >>>> >>> >>> >> > > >>>> >>> >>> >> > I'd call that a bug. It doesn't run, and there's no > reason > >>>> >>> >>> >> > why > >>>> >>> >>> >> > something > >>>> >>> >>> >> > not > >>>> >>> >>> >> > allowed by the grammar shouldn't be diagnosed at compile > >>>> >>> >>> >> > time, > >>>> >>> >>> >> > IMO. > >>>> >>> >>> >> > > >>>> >>> >>> >> > From _The Swift Programming Language_: > >>>> >>> >>> >> > > >>>> >>> >>> >> > GRAMMAR OF A STRING LITERAL > >>>> >>> >>> >> > string-literal → static-string-literal | > >>>> >>> >>> >> > interpolated-string-literal > >>>> >>> >>> >> > static-string-literal → "quoted-textopt" > >>>> >>> >>> >> > quoted-text → quoted-text-item quoted-textopt > >>>> >>> >>> >> > quoted-text-item → escaped-character > >>>> >>> >>> >> > quoted-text-item → Any Unicode scalar value except ", > \, > >>>> >>> >>> >> > U+000A, or > >>>> >>> >>> >> > U+000D > >>>> >>> >>> >> > interpolated-string-literal → "interpolated-textopt" > >>>> >>> >>> >> > interpolated-text → interpolated-text-item > >>>> >>> >>> >> > interpolated-textopt > >>>> >>> >>> >> > interpolated-text-item → \(expression) | > >>>> >>> >>> >> > quoted-text-item > >>>> >>> >>> >> > escaped-character → \0 | \\ | \t | \n | \r | \" | > \' > >>>> >>> >>> >> > escaped-character → \u{unicode-scalar-digits} > >>>> >>> >>> >> > unicode-scalar-digits → Between one and eight hexadecimal > >>>> >>> >>> >> > digit > >>>> >>> >>> >> > > >>>> >>> >>> >> > > >>>> >>> >>> >> >> > >>>> >>> >>> >> >> On Wed, Dec 28, 2016 at 1:20 PM, Xiaodi Wu > >>>> >>> >>> >> >> <xiaodi...@gmail.com> > >>>> >>> >>> >> >> wrote: > >>>> >>> >>> >> >> > On Wed, Dec 28, 2016 at 2:08 PM, Micah Hainline via > >>>> >>> >>> >> >> > swift-evolution > >>>> >>> >>> >> >> > <swift-evolution@swift.org> wrote: > >>>> >>> >>> >> >> >> > >>>> >>> >>> >> >> >> As an aide to learning I've been playing around with > >>>> >>> >>> >> >> >> implementation > >>>> >>> >>> >> >> >> of > >>>> >>> >>> >> >> >> some of these concepts in the compiler and a few > things > >>>> >>> >>> >> >> >> popped up > >>>> >>> >>> >> >> >> that > >>>> >>> >>> >> >> >> I'm not happy with. > >>>> >>> >>> >> >> >> > >>>> >>> >>> >> >> >> First, regarding the way #fileLiteral works, it > >>>> >>> >>> >> >> >> necessitates > >>>> >>> >>> >> >> >> the > >>>> >>> >>> >> >> >> addition of URL.init(fileReferenceLiteralResourceNa > me:) > >>>> >>> >>> >> >> >> which > >>>> >>> >>> >> >> >> takes > >>>> >>> >>> >> >> >> a > >>>> >>> >>> >> >> >> string but does not return an optional value. Fine, > >>>> >>> >>> >> >> >> except > >>>> >>> >>> >> >> >> that I > >>>> >>> >>> >> >> >> don't have to call #fileLiteral in my code to use > that > >>>> >>> >>> >> >> >> constructor, > >>>> >>> >>> >> >> >> I > >>>> >>> >>> >> >> >> can also use it directly. While I could get > >>>> >>> >>> >> >> >> compile-time > >>>> >>> >>> >> >> >> checking > >>>> >>> >>> >> >> >> on > >>>> >>> >>> >> >> >> the #fileLiteral, I can't on the direct constructor. > >>>> >>> >>> >> >> >> Additionally, I > >>>> >>> >>> >> >> >> could use the direct constructor with any String, not > >>>> >>> >>> >> >> >> just > >>>> >>> >>> >> >> >> literals. > >>>> >>> >>> >> >> >> Internally that will call ```self = > >>>> >>> >>> >> >> >> Bundle.main.url(forResource: > >>>> >>> >>> >> >> >> name, > >>>> >>> >>> >> >> >> withExtension: nil)!``` and crash at runtime if it's > >>>> >>> >>> >> >> >> not > >>>> >>> >>> >> >> >> found. > >>>> >>> >>> >> >> >> Clearly we do not intend that init to be called > >>>> >>> >>> >> >> >> directly, > >>>> >>> >>> >> >> >> but > >>>> >>> >>> >> >> >> that > >>>> >>> >>> >> >> >> isn't clear to new Swift user Jude Doe, who discovers > >>>> >>> >>> >> >> >> the > >>>> >>> >>> >> >> >> API as > >>>> >>> >>> >> >> >> xe > >>>> >>> >>> >> >> >> autocompletes from Xcode. > >>>> >>> >>> >> >> > > >>>> >>> >>> >> >> > > >>>> >>> >>> >> >> > That could be fixed with documentation. This API > design > >>>> >>> >>> >> >> > was > >>>> >>> >>> >> >> > reviewed > >>>> >>> >>> >> >> > and > >>>> >>> >>> >> >> > approved as part of SE-0039: > >>>> >>> >>> >> >> > > >>>> >>> >>> >> >> > > >>>> >>> >>> >> >> > > >>>> >>> >>> >> >> > > >>>> >>> >>> >> >> > > >>>> >>> >>> >> >> > https://github.com/apple/swift-evolution/blob/master/ > proposals/0039-playgroundliterals.md > >>>> >>> >>> >> >> > > >>>> >>> >>> >> >> >> > >>>> >>> >>> >> >> >> The second problem comes from String Interpolation. > >>>> >>> >>> >> >> >> It's a > >>>> >>> >>> >> >> >> basic > >>>> >>> >>> >> >> >> problem I think with anything that extends the > concept > >>>> >>> >>> >> >> >> of > >>>> >>> >>> >> >> >> the > >>>> >>> >>> >> >> >> string_literal with additional requirements that need > >>>> >>> >>> >> >> >> to be > >>>> >>> >>> >> >> >> checked > >>>> >>> >>> >> >> >> at > >>>> >>> >>> >> >> >> compile-time. Right now I can put in something like > >>>> >>> >>> >> >> >> ```#fileLiteral(resourceName: "\(myString)")```. > >>>> >>> >>> >> >> > > >>>> >>> >>> >> >> > > >>>> >>> >>> >> >> > Can you? SE-0039 says that resourceName should be a > >>>> >>> >>> >> >> > static-string-literal, > >>>> >>> >>> >> >> > which (unless I'm mistaken) should forbid > interpolation. > >>>> >>> >>> >> >> > > >>>> >>> >>> >> >> >> > >>>> >>> >>> >> >> >> While at one level it > >>>> >>> >>> >> >> >> might seem nice to be able to construct this sort of > >>>> >>> >>> >> >> >> thing, > >>>> >>> >>> >> >> >> it's > >>>> >>> >>> >> >> >> not > >>>> >>> >>> >> >> >> at all nice from a validation perspective. > >>>> >>> >>> >> >> >> > >>>> >>> >>> >> >> >> I think this has to be solved at a higher level, in > the > >>>> >>> >>> >> >> >> Lexer, > >>>> >>> >>> >> >> >> making > >>>> >>> >>> >> >> >> a url literal a concept at that level, and > >>>> >>> >>> >> >> >> fundamentally NOT > >>>> >>> >>> >> >> >> a > >>>> >>> >>> >> >> >> string > >>>> >>> >>> >> >> >> literal underneath, even if they shared some similar > >>>> >>> >>> >> >> >> constructs. > >>>> >>> >>> >> >> >> > >>>> >>> >>> >> >> >> The Lexer would be able to see #url("https:// > \(host)") > >>>> >>> >>> >> >> >> and > >>>> >>> >>> >> >> >> say > >>>> >>> >>> >> >> >> "Invalid escape sequence in literal, \( is not > >>>> >>> >>> >> >> >> understood as > >>>> >>> >>> >> >> >> a > >>>> >>> >>> >> >> >> url". > >>>> >>> >>> >> >> >> In fact, the URL literal should probably not need ANY > >>>> >>> >>> >> >> >> escape > >>>> >>> >>> >> >> >> sequences > >>>> >>> >>> >> >> >> or even the concept of escape sequences, since a > >>>> >>> >>> >> >> >> double-quote is > >>>> >>> >>> >> >> >> not > >>>> >>> >>> >> >> >> a > >>>> >>> >>> >> >> >> legal character in a URL. > >>>> >>> >>> >> >> >> > >>>> >>> >>> >> >> >> I definitely think we should take this opportunity to > >>>> >>> >>> >> >> >> identify > >>>> >>> >>> >> >> >> that > >>>> >>> >>> >> >> >> we > >>>> >>> >>> >> >> >> do NOT want to use string literal as it currently > >>>> >>> >>> >> >> >> stands as > >>>> >>> >>> >> >> >> a > >>>> >>> >>> >> >> >> base > >>>> >>> >>> >> >> >> construct for other literal types. Quite possibly > >>>> >>> >>> >> >> >> there's > >>>> >>> >>> >> >> >> another, > >>>> >>> >>> >> >> >> more restricted concept that we can draw out of > string > >>>> >>> >>> >> >> >> literal > >>>> >>> >>> >> >> >> that > >>>> >>> >>> >> >> >> would make a good base construct, but certainly not a > >>>> >>> >>> >> >> >> string > >>>> >>> >>> >> >> >> literal > >>>> >>> >>> >> >> >> with interpolation. > >>>> >>> >>> >> >> >> > >>>> >>> >>> >> >> >> > >>>> >>> >>> >> >> >> > >>>> >>> >>> >> >> >> > >>>> >>> >>> >> >> >> On Wed, Dec 28, 2016 at 8:01 AM, Jonathan Hull via > >>>> >>> >>> >> >> >> swift-evolution > >>>> >>> >>> >> >> >> <swift-evolution@swift.org> wrote: > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > On Dec 27, 2016, at 11:46 AM, David Sweeris > >>>> >>> >>> >> >> >> > <daveswee...@mac.com> > >>>> >>> >>> >> >> >> > wrote: > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > On Dec 22, 2016, at 11:39 PM, Jonathan Hull > >>>> >>> >>> >> >> >> > <jh...@gbis.com> > >>>> >>> >>> >> >> >> > wrote: > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > On Dec 20, 2016, at 12:29 PM, David Sweeris > >>>> >>> >>> >> >> >> > <daveswee...@mac.com> > >>>> >>> >>> >> >> >> > wrote: > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > On Dec 20, 2016, at 2:11 AM, Jonathan Hull via > >>>> >>> >>> >> >> >> > swift-evolution > >>>> >>> >>> >> >> >> > <swift-evolution@swift.org> wrote: > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > Yes, I agree. I am excited to see what happens in > >>>> >>> >>> >> >> >> > phase > >>>> >>> >>> >> >> >> > 2. > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > What I am suggesting here is slightly different. > >>>> >>> >>> >> >> >> > Basically > >>>> >>> >>> >> >> >> > being > >>>> >>> >>> >> >> >> > able > >>>> >>> >>> >> >> >> > to > >>>> >>> >>> >> >> >> > use > >>>> >>> >>> >> >> >> > RegEx (with capture groups) as a shorthand for a > type > >>>> >>> >>> >> >> >> > composed > >>>> >>> >>> >> >> >> > of > >>>> >>> >>> >> >> >> > base > >>>> >>> >>> >> >> >> > literals. For example: (StringLiteral, > >>>> >>> >>> >> >> >> > [IntegerLiteral]). > >>>> >>> >>> >> >> >> > Named > >>>> >>> >>> >> >> >> > capture > >>>> >>> >>> >> >> >> > groups could even map to a dictionary literal. I > am > >>>> >>> >>> >> >> >> > using > >>>> >>> >>> >> >> >> > “RegEx > >>>> >>> >>> >> >> >> > goes > >>>> >>> >>> >> >> >> > Here” > >>>> >>> >>> >> >> >> > to represent RegEx in the examples below, but > >>>> >>> >>> >> >> >> > hopefully it > >>>> >>> >>> >> >> >> > will > >>>> >>> >>> >> >> >> > get > >>>> >>> >>> >> >> >> > it’s > >>>> >>> >>> >> >> >> > own > >>>> >>> >>> >> >> >> > literal type in Xcode (Imagine that replacing it > >>>> >>> >>> >> >> >> > here). > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > func foo( _ param: “RegExGoesHere”) {…} > //Definition > >>>> >>> >>> >> >> >> > uses > >>>> >>> >>> >> >> >> > a > >>>> >>> >>> >> >> >> > RegEx > >>>> >>> >>> >> >> >> > where > >>>> >>> >>> >> >> >> > the > >>>> >>> >>> >> >> >> > type would normally be > >>>> >>> >>> >> >> >> > foo(“my parseable string") //Calling with a string > >>>> >>> >>> >> >> >> > literal > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > In this case, ‘param’ takes a string literal when > >>>> >>> >>> >> >> >> > called > >>>> >>> >>> >> >> >> > but > >>>> >>> >>> >> >> >> > the > >>>> >>> >>> >> >> >> > compiler > >>>> >>> >>> >> >> >> > converts it to a tuple of literals based on the > regEx > >>>> >>> >>> >> >> >> > supplied > >>>> >>> >>> >> >> >> > and > >>>> >>> >>> >> >> >> > passes > >>>> >>> >>> >> >> >> > that tuple the function. The type/structure of the > >>>> >>> >>> >> >> >> > tuple > >>>> >>> >>> >> >> >> > is > >>>> >>> >>> >> >> >> > defined > >>>> >>> >>> >> >> >> > by > >>>> >>> >>> >> >> >> > the > >>>> >>> >>> >> >> >> > capture groups in the RegEx > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > The parameter above would only allow string > literals > >>>> >>> >>> >> >> >> > to be > >>>> >>> >>> >> >> >> > passed > >>>> >>> >>> >> >> >> > in, > >>>> >>> >>> >> >> >> > and > >>>> >>> >>> >> >> >> > would give a compiler error if you tried to pass a > >>>> >>> >>> >> >> >> > variable or > >>>> >>> >>> >> >> >> > if > >>>> >>> >>> >> >> >> > the > >>>> >>> >>> >> >> >> > string > >>>> >>> >>> >> >> >> > didn’t conform to the supplied RegEx. To allow > >>>> >>> >>> >> >> >> > passing > >>>> >>> >>> >> >> >> > String > >>>> >>> >>> >> >> >> > variables > >>>> >>> >>> >> >> >> > you > >>>> >>> >>> >> >> >> > would have to add either ‘?’ or ‘!’ after the RegEx > >>>> >>> >>> >> >> >> > definition > >>>> >>> >>> >> >> >> > to > >>>> >>> >>> >> >> >> > handle > >>>> >>> >>> >> >> >> > the > >>>> >>> >>> >> >> >> > case where the value doesn’t conform. > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > func foo( _ param: “RegExGoesHere”?) {…} //‘param' > is > >>>> >>> >>> >> >> >> > nil > >>>> >>> >>> >> >> >> > if > >>>> >>> >>> >> >> >> > RegEx > >>>> >>> >>> >> >> >> > fails > >>>> >>> >>> >> >> >> > foo(myStringVar) //Calling > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > func bar( _ param: “RegExGoesHere”!) {…} //fatal > >>>> >>> >>> >> >> >> > error if > >>>> >>> >>> >> >> >> > RegEx > >>>> >>> >>> >> >> >> > fails > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > When a variable is passed, the RegEx is performed > at > >>>> >>> >>> >> >> >> > runtime > >>>> >>> >>> >> >> >> > instead > >>>> >>> >>> >> >> >> > of > >>>> >>> >>> >> >> >> > compile time. > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > Once you have this, the syntax to add new literal > >>>> >>> >>> >> >> >> > types/initializers > >>>> >>> >>> >> >> >> > falls > >>>> >>> >>> >> >> >> > out virtually for free. > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > Is “RegExGoesHere” where the regex pattern goes, or > >>>> >>> >>> >> >> >> > where > >>>> >>> >>> >> >> >> > the > >>>> >>> >>> >> >> >> > string > >>>> >>> >>> >> >> >> > you’re > >>>> >>> >>> >> >> >> > trying to match goes? If it’s the latter, where > does > >>>> >>> >>> >> >> >> > the > >>>> >>> >>> >> >> >> > pattern > >>>> >>> >>> >> >> >> > go? > >>>> >>> >>> >> >> >> > If > >>>> >>> >>> >> >> >> > it’s > >>>> >>> >>> >> >> >> > the former, where does the string you’re trying to > >>>> >>> >>> >> >> >> > match > >>>> >>> >>> >> >> >> > go? > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > “RegExGoesHere” is where the pattern goes (instead > of > >>>> >>> >>> >> >> >> > the > >>>> >>> >>> >> >> >> > type). > >>>> >>> >>> >> >> >> > The > >>>> >>> >>> >> >> >> > string > >>>> >>> >>> >> >> >> > you are trying to match gets passed in as the > >>>> >>> >>> >> >> >> > parameter > >>>> >>> >>> >> >> >> > (e.g. > >>>> >>> >>> >> >> >> > “my > >>>> >>> >>> >> >> >> > parseable > >>>> >>> >>> >> >> >> > string”). > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > Ah, ok, I think I understand what you’re saying > >>>> >>> >>> >> >> >> > now... > >>>> >>> >>> >> >> >> > You’re > >>>> >>> >>> >> >> >> > suggesting > >>>> >>> >>> >> >> >> > that instead of defining a custom type that > conforms > >>>> >>> >>> >> >> >> > to > >>>> >>> >>> >> >> >> > “RegExLiteral” > >>>> >>> >>> >> >> >> > (or > >>>> >>> >>> >> >> >> > some other mechanism) and using that as the > >>>> >>> >>> >> >> >> > parameter’s > >>>> >>> >>> >> >> >> > type, > >>>> >>> >>> >> >> >> > you > >>>> >>> >>> >> >> >> > put > >>>> >>> >>> >> >> >> > your > >>>> >>> >>> >> >> >> > regex pattern as the type directly? > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > Yes. It is admittedly an advanced feature, but I > >>>> >>> >>> >> >> >> > think it > >>>> >>> >>> >> >> >> > would > >>>> >>> >>> >> >> >> > be a > >>>> >>> >>> >> >> >> > useful > >>>> >>> >>> >> >> >> > one. > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > Thanks, > >>>> >>> >>> >> >> >> > Jon > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > > >>>> >>> >>> >> >> >> > _______________________________________________ > >>>> >>> >>> >> >> >> > 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 > >>>> >>> >>> >> >> > > >>>> >>> >>> >> >> > > >>>> >>> >>> >> >> _______________________________________________ > >>>> >>> >>> >> >> 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 > >>>> >>> >>> > > >>>> >>> >>> > > >>>> >>> >> > >>>> >>> >> > >>>> >> > >>>> >> > >>>> > > >>> > >>> > >> > > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution