This might be a little confusing for users, as Swift 5.7-as-compiled-using-default-Xcode-settings would be a different dialect of the language in a prominent way from Swift 5.7-as-compiled-otherwise, if I am to understand it? If the feature is mature enough for Swift-on-Xcode-14, should we be considering to just turn it on by default in Swift 5.7 everywhere?
10 Likes
I realized that my code actually builds without turning the regex literals off, I just had to break up lines that had two CasePaths. And applying @hamishknight's workaround with comments on the lines that were breaking the previews also worked.
I also agree with @xwu that having Swift default one way and Xcode another is effectively a language dialect given code could succeed or fail depending on which one you're using.
3 Likes
How about letting the SPM tools version set the flag? That would maintain compatibility with existing code, and allow new projects to migrate to the new behaviour by updating their tools version, so it could be deployed now.
IIRC that’s actually how we set the language mode in the first place, isn’t it? Like, nobody has to write that they want Swift 5 mode instead of 4.2 mode, because it’s inferred by the tools version. Presumably the same will happen with Swift 6.
We can do the same thing right now for the regex flag. Or declare it as “Swift 5.7 mode”.
It would be intesting to know whether adding the "no trailing space and the end of a regex" rule would have obviated the need to do that.
Namely, lines like this were broken:
.pullback(state: /AppState.UserState.signedOut, action: /.self)
It seems like more invalid trailing bits may help as well. Do regex literals have methods that can be called?
Literals don't have methods, but the types they create do, so yes, /.../.self is valid code. But in your example, if we did apply a matching rule that a regex literal can't end with a space, this would parse as two prefix operators without you having to update the code.
2 Likes
Would this rule be only for Swift 5.x mode? I frequently write awk programs that rely on matching leading or trailing whitespace.
you still can, via e.g /\ / and /\s/, as well as #/ /#
2 Likes
I'd probably use the #/ /# syntax for regexes containing leading/trailing spaces, or anything else that looks similarly ambiguous (either to the compiler or to humans).
We've gotten quite a bit of communication around these Xcode bugs breaking apps that use case paths 
Most of them center around the following:
-
The above-mentioned Xcode preview bug (luckily worked around with trailing comment)
-
The bare syntax default is confusing folks that use multiple case paths per line and need to explicitly disambiguate (@Jon_Shier mentioned this above above). Is this definitely supposed to be the default in Xcode when it's not the default in Swift 5.7?
-
Using a case path breaks syntax highlighting and the rest of a file's indentation due to being treated like an open regex (is there a workaround for this?)
What should our messaging be to library users encountering these issues? Should they all be duping feedback?
6 Likes
Having a measure of both (1) how many people this is affecting and (2) the exact code that's breaking would both be very valuable.
2 Likes
It's especially useful to give code snippets from the app that would indicate if a trailing space rule with literals would help or not.
3 Likes
Right, that's a great example of why having the exact code is important. We need to understand if the specific breakage is unavoidable, or if it's something that could be patched with a better lexing rule.
We've gotten a few tweets, 3 duplicate issues on GitHub (we've since pinned an issue to hopefully prevent more dupes), and a handful of fairly active Slack conversations since Monday. I'll note on the issue to report back here with examples, but in general this doesn't seem like something we can accurately measure, since most people will probably encounter our pinned issue and leave it alone for now.
The majority of conversation is around the Xcode previews bug and the Xcode syntax highlighting and indentation bugs, though, and not multiple case paths on a single line.
4 Likes
Would this pull request resolve the outstanding issues, or is it too far away from the pitch stage to make a difference to those affected? Implement Enum Case KeyPaths by Azoy · Pull Request #58940 · apple/swift · GitHub
1 Like
Native case paths would fix the problem in the sense that there will be a first-class language solution that people can adopt that resolves the collision with / as a regex delimiter. They will not fix the problem of "people have code that previously worked but is broken today", because existing code will still use / until updated. The flag to disable bare slash regex delimiters is the appropriate short-term workaround for that problem, subject to the limitations in the Xcode beta discussed upthread.
4 Likes
Just as a side note, the PR referenced only implements the "extract" side of case paths, which while huge and a greatly appreciated addition to the language, would still not resolve the issues outside of source compatibility because most libraries that utilize case paths primarily depend on the ability to also generically "embed" values into root enums.
4 Likes
I'm having problem with current Xcode 14 Beta 1's Regex Literal since my library heavily relying on CasePaths.
Build works fine, but IDE highlighting and indentation is broken.
Example code:
How it looks:
Review Conclusion
The review has ended and the proposal has been accepted with modifications.
2 Likes
Hi @inamiy – as you note, this is specific to Xcode’s editor rather than the language/compiler. I believe this should be resolved in the latest beta, but do file a feedback if you think there are still cases that it is not correctly handling. Thanks!
2 Likes