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.
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?
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.