-
Notifications
You must be signed in to change notification settings - Fork 3.1k
SI-8022 Backwards compatibility for Regex#unapplySeq #3207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The change in ce1bbfe / SI-6406 introduced overloads of `unapplySeq` with wider static and dynmaic result types than the now-deprecated alternative that accepted `Any`. This is subtly source incompatible and the change was noticed in Specs2. This commit uses `List` as the static and runtime type for the new overloads. For consistency, the same is done for the new method added in SI-7737 / 93e9623.
I wonder whether there is latitude for a |
Bummer. IIRC, this was a conscious change, though not a point of emphasis. Specs2 is a rather demanding codebase. |
We're tantalizingly close to having nightly builds that will catch this. Overloading and source compatibility is a bit of a minefield. |
LGTM. I'll study why 2.11 is not carte blanche on compatibility. |
SI-8022 Backwards compatibility for Regex#unapplySeq
Because we want people to upgrade. Recompiling is about all you can ask for. (And compiling with deprecations as fatal warnings.) |
This change was so subtle that it could go unnoticed. It took me a number of hours to pin it down in specs. The meta problem is that pattern matching makes type tests so easy that changing even the runtime types can be a breaking change |
That makes me feel worse about it. BTW, I looked at the string interp warning; just trying to see how to detect we were a macro expansion; I saw code that looked like there's an attachment, but my test to look for it didn't work the first time; I'll get back to it soon. |
The string interp thing is pretty specific to specs2, as it does some strange tricks to extract a chunk of source code (sort of undoing the parsers work) and synthesizes a string literal from that. I guess you've seen that, based on your mention of macros. The attachment you mention might not be added until after the warning has been issued. Let me know if you can't find a suitable way to detect this, and I'll help find a way. |
BTW, touching on consistency,
|
The change in ce1bbfe / SI-6406 introduced overloades of
unapplySeq
with wider static and dynmaic result typesthan the now-deprecated alternative that accepted
Any
.This is subtly source incompatible and the change was noticed
in Specs2.
This commit uses
List
as the static and runtime type forthe new overloads.
For consistency, the same is done for the new method added
in SI-7737 / 93e9623.
Review by @som-snytt