SE-0354 (Second Review): Regex Literals

[xwu (Xiaodi Wu)]

@hamishknight

@Michael_Ilseman

@hamishknight What's the status of the no-trailing-whitespace rule? Is it desirable, or not, and would it fix this issue?

I think it's desirable if it avoids breaking source in cases that are somewhat common. It would indeed fix this particular issue. However, at least from the source compatibility testing we've done so far, I'm not entirely sure that these cases are particularly common. I still remain slightly concerned that such a rule could potentially lead to an odd editing experience (i.e while typing a regex containing spaces, the literal would change meaning if space is the current character being typed, assuming both delimiters are present during typing). I think we may want to get the core team's opinion on the tradeoff being made here.

I'd like to echo that it'd be really great to get some consideration of this—not only for avoiding nearly any source breaks, but also because it kind of makes sense from an aesthetic standpoint that neither leading nor trailing whitespace would be permitted.

(And I don't mean "aesthetic" here solely to mean the kind of satisfaction that one gets from an elegant math proof or something, but also—more crucially—in the sense that users who see foo(/, /) with their squishy human eyeballs are likely to interpret it in a certain way due to how they've been conditioned to make of whitespace, and it would be more user-friendly if Swift's actual rules aligned with that intuition.)

As I said earlier, I agree that the editing experience is a legitimate consideration, but in the case of a regex, when typing out a line that starts something like let x = /, I can't see how an editor would know to insert a closing delimiter, and in the absence of a paired / the syntax highlighting wouldn't flit back and forth between regex and non-regex in the scenario where a user is typing out a new line of code.

@hamishknight

A couple of other ways of suppressing the warning could be:

• Use an inline comment foo(?#)bar
• Just write it as foobar instead
• Have the warning be suppressed if you explicitly write (?x) in the regex

The latter in particular seems quite reasonable to me, assuming that intentional non-semantic whitespace between literal characters isn't a case that comes up too often.

...What if, instead of supporting bare multiline #/ ... /# and merely suppressing warnings with (?x) in the regex, we required an explicit opening #/(?-x) in order to use a multiline literal at all?

It would (a) have the advantage of being very explicit about the change in syntactic behavior going from a one-line literal to a multi-line literal; while (b) still answering @Michael_Ilseman's rationale for supporting multiline literals in the first place; and (c) hewing to the insightful analysis that "Region 2" of the design space (semantic whitespace in multiline literals) is undesirable.

Yes, the syntax becomes more verbose, but in this context we're talking about a regex literal that's complicated enough to be best written spanning multiple lines, perhaps including comments just to explain what's going on. Being required to throw in a few characters for an explicit indicator of how whitespace is being handled doesn't seem so outlandish.