URL Literals

xwu · December 20, 2016, 4:28pm

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 better regex support comes to Swift, I'm sure there will be an
ExpressibleByRegexLiteral. The missing piece, though, is to have a way to
indicate that some pure function (or in this case, initializer) can be
evaluated at compile time if possible. Once we have that, your desired
solution falls out for free.

Once you have this, the syntax to add new literal types/initializers falls

···

On Tue, Dec 20, 2016 at 4:11 AM, Jonathan Hull <jhull@gbis.com> wrote:

out virtually for free.

Thanks,
Jon

On Dec 19, 2016, at 8:02 PM, Erica Sadun <erica@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 <jhull@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 <davesweeris@mac.com> >> wrote:
>>
>>
>>
>> Sent from my iPhone
>>
>>> On Dec 17, 2016, at 13:20, David Sweeris <davesweeris@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

David_Sweeris · December 20, 2016, 8:29pm

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?

Also, it’s worth noting that I don’t think you can just use Strings to hold arbitrary regular expressions… According to “Daveo” (not me) on stackoverflow (javascript - What is a good regular expression to match a URL? - Stack Overflow), the regex for the regex for an URL is:
[-a-zA-Z0-9@:%._\+~#=]{2,256}\.[a-z]{2,6}\b([-a-zA-Z0-9@:%_\+.~#?&//=]*)
But pasting this into a string literal gives several “Invalid escape sequence in literal” errors.

- Dave Sweeris

···

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.

David_Sweeris · December 20, 2016, 8:46pm

Oops… typo...

···

On Dec 20, 2016, at 12:29 PM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

[...] According to “Daveo” (not me) on stackoverflow (javascript - What is a good regular expression to match a URL? - Stack Overflow), the regex for the regex for an URL is: […]

That “for the regex” in the middle of the text after the link shouldn’t be there… The regex I posted supposedly matches URLs, not strings which would themselves form a regex that would match URLs.

hehe… nested regexing… that’s gotta be useful for something… lol

- Dave Sweeris

David_Sweeris · December 20, 2016, 8:52pm

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 better regex support comes to Swift, I'm sure there will be an ExpressibleByRegexLiteral.

Yeah, once we get regex support, I’d push for an `ExpressibleByRegexLiteral` regardless of how the rest of this URL Literal proposal works out. I’m curious as whether that would be more flexible or less, compared to the “ExpressibleByValidated*Literal” idea. Especially WRT call-site syntax, since my understanding is that it’s much simpler to go back and rework architectural stuff later on if you can keep the call-site syntax the same.

The missing piece, though, is to have a way to indicate that some pure function (or in this case, initializer) can be evaluated at compile time if possible. Once we have that, your desired solution falls out for free.

Does anyone have any issues with the requirements I posted earlier in the thread (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161212/029497.html\)? AFAIK, I think it’s reasonably complete* for constant expressions. As a bonus (IMHO, anyway) adding `@constexpr` would lay the groundwork for adding `@pure` later on, both in terms of language precedent and probably with the complier-side work for validating that an expression really is what we claim it is, too.

- Dave Sweeris

*One could argue that allowing read-only access to files, while probably not in the “spirit” of constant expressions, probably wouldn’t break anything and could be very useful for changing the compiled code based on settings in a configuration file. I don’t have enough experience in the area to have a strong opinion on this particular point.

···

On Dec 20, 2016, at 8:28 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Tue, Dec 20, 2016 at 4:11 AM, Jonathan Hull <jhull@gbis.com <mailto:jhull@gbis.com>> wrote:

Jon_Hull · December 23, 2016, 7:39am

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”).

Also, it’s worth noting that I don’t think you can just use Strings to hold arbitrary regular expressions… According to “Daveo” (not me) on stackoverflow (javascript - What is a good regular expression to match a URL? - Stack Overflow), the regex for the regex for an URL is:
[-a-zA-Z0-9@:%._\+~#=]{2,256}\.[a-z]{2,6}\b([-a-zA-Z0-9@:%_\+.~#?&//=]*)
But pasting this into a string literal gives several “Invalid escape sequence in literal” errors.

Yes, we would use whatever URL Literal type they come up with in phase 2.

Thanks,
Jon

···

On Dec 20, 2016, at 12:29 PM, David Sweeris <davesweeris@mac.com> wrote:

On Dec 20, 2016, at 2:11 AM, Jonathan Hull via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

gmosx · December 23, 2016, 7:14am

As a bonus (IMHO, anyway) adding `@constexpr` would lay the groundwork for adding `@pure` later on, both in

Could that be just `@const` (since that keyword is not reserved yet)? Or something else?

It bugs be that the `constexpr` keyword is hard to pronounce (and lacks a separator between the two constituent words). Even just `const`.

-g.

David_Sweeris · December 27, 2016, 7:46pm

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?

- Dave Sweeris

···

On Dec 22, 2016, at 11:39 PM, Jonathan Hull <jhull@gbis.com> wrote:

On Dec 20, 2016, at 12:29 PM, David Sweeris <davesweeris@mac.com <mailto:davesweeris@mac.com>> wrote:

On Dec 20, 2016, at 2:11 AM, Jonathan Hull via swift-evolution <swift-evolution@swift.org <mailto: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”).

xwu · December 23, 2016, 7:31am

We're nowhere close to bikeshedding the name yet; people are calling it
constexpr to mean that the idea is something along the lines of C++'s
constexpr, as opposed to C++'s const. Mentally substitute whatever word you
want at the moment.

···

On Fri, Dec 23, 2016 at 02:15 Georgios Moschovitis < george.moschovitis@icloud.com> wrote:

> As a bonus (IMHO, anyway) adding `@constexpr` would lay the groundwork
for adding `@pure` later on, both in

Could that be just `@const` (since that keyword is not reserved yet)? Or
something else?

It bugs be that the `constexpr` keyword is hard to pronounce (and lacks a
separator between the two constituent words). Even just `const`.

-g.

Jon_Hull · December 28, 2016, 2:01pm

Yes. It is admittedly an advanced feature, but I think it would be a useful one.

Thanks,
Jon

···

On Dec 27, 2016, at 11:46 AM, David Sweeris <davesweeris@mac.com> wrote:

On Dec 22, 2016, at 11:39 PM, Jonathan Hull <jhull@gbis.com <mailto:jhull@gbis.com>> wrote:

On Dec 20, 2016, at 12:29 PM, David Sweeris <davesweeris@mac.com <mailto:davesweeris@mac.com>> wrote:

On Dec 20, 2016, at 2:11 AM, Jonathan Hull via swift-evolution <swift-evolution@swift.org <mailto: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?

Micah_Hainline · December 28, 2016, 7:08pm

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(fileReferenceLiteralResourceName:) 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.

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)")```. 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 <davesweeris@mac.com> wrote:

On Dec 22, 2016, at 11:39 PM, Jonathan Hull <jhull@gbis.com> wrote:

On Dec 20, 2016, at 12:29 PM, David Sweeris <davesweeris@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

xwu · December 28, 2016, 7:20pm

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(fileReferenceLiteralResourceName:) 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:

github.com

apple/swift-evolution/blob/main/proposals/0039-playgroundliterals.md

# Modernizing Playground Literals

* Proposal: [SE-0039](0039-playgroundliterals.md)
* Author: [Erica Sadun](http://github.com/erica)
* Review Manager: [Chris Lattner](https://github.com/lattner)
* Status: **Implemented (Swift 3)**
* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0039-modernizing-playground-literals/1746)
* Bug: [SR-917](https://bugs.swift.org/browse/SR-917)

## Introduction

Playground literals tokenize colors, files, and images. They provide drag-and-drop convenience and
in-context visualizations that offer easy reference and manipulation when designing playground content.
These literals are built using a simple square bracket syntax that, in the current form, 
conflicts with collection literals.
This proposal redesigns playground literals to follow the precedent of #available and #selector.

*Discussion took place on the Swift Evolution mailing list in the [\[Discussion\] Modernizing Playground Literals](https://forums.swift.org/t/discussion-modernizing-playground-literals/1443) thread. Thanks to [Chris Lattner](https://github.com/lattner) for suggesting this enhancement.*

[Review](https://forums.swift.org/t/review-se-0039-modernizing-playground-literals/1707)

This file has been truncated. show original

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.

···

On Wed, Dec 28, 2016 at 2:08 PM, Micah Hainline via swift-evolution < swift-evolution@swift.org> wrote:

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 <davesweeris@mac.com> wrote:
>
>
> On Dec 22, 2016, at 11:39 PM, Jonathan Hull <jhull@gbis.com> wrote:
>
>
> On Dec 20, 2016, at 12:29 PM, David Sweeris <davesweeris@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

Micah_Hainline · December 28, 2016, 7:29pm

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!

···

On Wed, Dec 28, 2016 at 1:20 PM, Xiaodi Wu <xiaodi.wu@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(fileReferenceLiteralResourceName:) 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 <davesweeris@mac.com> wrote:
>
>
> On Dec 22, 2016, at 11:39 PM, Jonathan Hull <jhull@gbis.com> wrote:
>
>
> On Dec 20, 2016, at 12:29 PM, David Sweeris <davesweeris@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

xwu · December 28, 2016, 7:36pm

> 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 2:29 PM, Micah Hainline via swift-evolution < swift-evolution@swift.org> wrote:

On Wed, Dec 28, 2016 at 1:20 PM, Xiaodi Wu <xiaodi.wu@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(fileReferenceLiteralResourceName:) 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 <davesweeris@mac.com> > wrote:
>> >
>> >
>> > On Dec 22, 2016, at 11:39 PM, Jonathan Hull <jhull@gbis.com> wrote:
>> >
>> >
>> > On Dec 20, 2016, at 12:29 PM, David Sweeris <davesweeris@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

David_Sweeris · December 28, 2016, 9:03pm

I'm a bit surprised that part of compiling the compiler doesn't seem to involve parsing these kinds of grammar specs directly to generate the code used to identify literals. (Or maybe it does and and we just forgot to sync up the grammar specs and the docs before the last release.)

- Dave Sweeris

···

On Dec 28, 2016, at 11:36, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> 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

Micah_Hainline · December 28, 2016, 7:44pm

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.wu@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.wu@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(fileReferenceLiteralResourceName:) 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 <davesweeris@mac.com> >> >> > wrote:
>> >
>> >
>> > On Dec 22, 2016, at 11:39 PM, Jonathan Hull <jhull@gbis.com> wrote:
>> >
>> >
>> > On Dec 20, 2016, at 12:29 PM, David Sweeris <davesweeris@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