SE-0354: Regex Literals

I would not be surprised if there are cases of people using /// instead of regular comments inside function bodies. That being said, at least those cases would be straightforward to fix. The main issue with restricting this to only within function bodies is that multi-line regex literals would then be unusable (or require additional #s) at the top level of a main.swift file or playground. And IMO it doesn't seem unreasonable to want to write documentation comments in those cases.

I don't think it's impossible to get /// working in most cases, we might be able to leverage the parser's isStartOfSwiftDecl heuristic to exclude most/all of the cases where you have a documentation comment. You then wouldn't be able to start a multi-line regex with a decl introducer keywords like var, func, or class. However it would add even more complexity to source tooling such as syntax highlighting. Additionally, it's possible the editor may no longer be able to automatically insert /// to continue a documentation comment in case you are trying to write a regex.

Now, this might be a worthwhile tradeoff if it's felt that the delimiter is worth it, but I'm not entirely sure whether it is. While it does nicely mirror """, it doesn't have the same semantics due to whitespace being non-semantic. In that regard, it could be argued that it's more surprising than mutli-line #/. It additionally doesn't have the same term-of-art or conciseness benefits that /.../ has.


13 posts were merged into an existing topic: SE-0354 (Second Review): Regex Literals

Hold up! I know there were questions about whether whitespace should be non-semantic or not in the various modes, but it had utterly escaped my attention that we have this inconsistency here. Even if whitespaces are semantic in multiline regex literals, one would expect the leading and trailing newlines to be ignored by analogy with string literals. Is this not proposed to be the case? If not, why not?

1 Like

2 posts were merged into an existing topic: SE-0354 (Second Review): Regex Literals

Was this change upstreamed in the proposal, or is there an edited version somewhere? It still deprecates prefix / in the proposal.

I have a PR up to amend the proposal: [SE-0354] Update regex literal proposal by hamishknight · Pull Request #1651 · apple/swift-evolution · GitHub


Can I check if this question is addressing the proposal, or @Paul_Cantrell's thoughts?

The proposal is that with multi-line literals, whitespace is not semantic. So leading and trailing newlines are ignored, not just by analogy with string literals but because all whitespace is ignored.

I was asking about the proposal; this makes sense.

I think I misunderstood @Paul_Cantrell's example, where it's the internal space between "hello" and "world" that becomes ignored in the case of a multiline literal, causing it not to match "hello world". That's...unfortunate but a different issue.

1 Like

Review Update

The core team has decided to return the proposal for revision and a second review is now running.

I have moved some of the recent discussion to that review thread.