SE-0354: Regex Literals

[Douglas_Gregor]

@allevato

@Jumhyn

I initially expressed ambivalence about this, but other comments have convinced me that this is a surprising departure from precedent that I don't believe has been adequately addressed in the review thread (unless I've missed a comment somewhere), and I'm not sure I understand the implications.

Would a later proposal (such as improved optics features) which had to make source-breaking changes to the bare regex syntax be considered 'truly' source breaking, since it would break -enable-bare-regex-syntax mode? Why is this being proposed as a production flag rather than an unreviewed -enable-experimental-bare-regex-syntax ?

Yes, this is quite a surprising departure from what we've been told in the past about not wanting there to be different "dialects of Swift" via the use of feature flags.

I commented about this earlier in the thread. To quote myself:

@Douglas_Gregor

The proposed /.../ source break is gentler than what we did with await , because it's under the control of a flag. In the run-up to Swift 6, we should be embracing this approach wholeheartedly, such that each Swift 6 source break has a flag associated with it so folks can nudge their Swift 5.x code along toward Swift 6 incrementally, gaining the benefits that came with each of these changes. I have a design in mind for this that I'll bring up in another discussion.

I just started a separate thread to discuss this promised design. My central thesis here is that we want to have a general way for Swift 5.x to opt into the source-breaking changes we've queued up for Swift 6 one at a time. This keeps coming up for Swift 6 features (-warn-concurrency for data-race safety; requests for a "require any on all existentials" mode) because folks want to adopt new features as soon as they can. This isn't creating permanent dialects, which we want to avoid: it's creating an incremental adoption path that smooths the transition to Swift 6. This way, developers won't have to confront every single breaking change all at once when they flip the language mode, which could be daunting. We can do better for the incremental adoption path and also get the syntax we want.

We have already made a number of source-breaking changes to the language that are queued up for Swift 6, and several of them have far larger impact on source code than what's being discussed here (any and Sendable checking will hit pretty much every bit of Swift code everywhere). We have to manage this transition well, or we'll end up with a permanent Swift 5/6 split. Against that backdrop, I consider the problems with the source-break of /.../ to be fairly minor.

That's why I'm looking for arguments as to why /.../ is the wrong destination that don't rely on the source compatibility angle. There really haven't been that many---folks that only want #/.../# but not /.../ tend to cite source compatibility alone. #regex(...) gained early favor in this thread, but I've already said why I think it's worse than the other options presented.

Doug