SE-0354: Regex Literals

[Douglas_Gregor]

@johnno1962

But avoiding source breaks is important Doug

(snip)

@johnno1962

For me the strategy of managing the transition using feature flags is worse than the original problem, breaking the idea that Swift syntax is a linear progression forward. Far better not to create the problem in the first place no?

We have a number of source breaks queued up for Swift 6 already, as noted in my other thread, all of which have already gone through the evolution process. You can make a consistent argument that all of those are bad, if you'd like, and we should retract or rework every one of those accepted proposals.

However, I have yet to hear objective argument that this source break is worse than those other, accepted source breaks. It's certainly not true based on the scale of the break---several of those changes have much more widespread effect, both in terms of the # of projects effected and how much work there is to resolve the break.

@johnno1962

even one of the proposal authors conceded this was a showstopper during the pitch phase.

(Ignoring the already-discussed issue with the quote above, I want to make a different point)

We should all be open to changing our minds as good arguments and improvements come up in the discussion. And we should encourage folks who have changed their minds to say so, especially proposal authors who quite literally set the flow of the conversation by making specific, actionable proposals.

@johnno1962

The result is weird escaping rules and whitespace sensitivity that needs to be documented and the occasional mis-parses that have already been mentioned.

Swift has whitespace sensitivity in quite a number of places, including around operators, with calls, with multi-line string literals, and with disambiguating < between a less-than operator and a generic parameter list. The rules of these were debated at length, and if you wrote them all out in great detail, as has been done with /.../ here, they'd be pretty scary, too. But they rarely come up in practice, so we get to use < as both a generic-parameter-list introducer and a custom operator, ( for both calls and tuples, etc.

I mean, isn't it confusing that

let x = someLongFunctionName(a)

and

let x = someLongFunctionName
         (a)

Have different meanings? What about:

3.14159

vs.

3
.14159

Should we have picked a different syntax for tuple literals, array literals, dictionary literals, and floating point literals because the newline rule is weird and we can come up with confusing cases? Or do those confusing cases come up so rarely, and are diagnosed so easily in the compiler, that fixating on them leads us down a road to worse overall design?

@Panajev

Another reasons some, like myself, disagree it is the right destination tend to also note how it adds a lot more frequent noise in the regex itself having to escape / which is not so infrequent in non trivially short regexes.

This seems to be a common argument:

@jayton

If the answer to that is to use “extended” literals either every time a slash is needed, or all the time, it’s hard to see how using /.../ some of the time will be an aesthetic or legibility advantage.

That exact same argument applies to escaping " in string literals. Is the use of "..." for string literals also a mistake, and Swift really should have required #"..."# for all string literals because some of them would need to escape the "?

I don't see why regex literals with / are special here. Rather, I think they should follow what string literals do: there's a single-character delimiter (/ for regex, " for string) and if you need that character within the literal, you either escape it or go to the raw form (#/.../# or #"..."#).

Let's imagine we take just #/.../#: how would we explain the inconsistency between regex literals and string literals to a Swift developer that didn't follow this discussion?

I keep seeing the assertion that "there's nothing to recommend the bare /.../" syntax, so I'll try to summarize in bullets real quick:

• /.../ is precedented in several other languages

• /.../ is analogous to the other literals in the language, nearly all of which have special parsing rules whose potential for confusion has not had a practical impact

• #/.../# is useful for the case where there is a need to escape / or go multi-line, but is unnecessary noise for the vast majority of regex literals

  Doug