Skip to content

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

Merged
merged 1 commit into from
Dec 2, 2013

Conversation

retronym
Copy link
Member

@retronym retronym commented Dec 1, 2013

The change in ce1bbfe / SI-6406 introduced overloades 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.

Review by @som-snytt

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.
@retronym
Copy link
Member Author

retronym commented Dec 1, 2013

I wonder whether there is latitude for a Lint warning when using :: to match on Seq, as in : https://github.com/retronym/scala/compare/topic/warn-match-seq-list

@som-snytt
Copy link
Contributor

Bummer. IIRC, this was a conscious change, though not a point of emphasis. Specs2 is a rather demanding codebase.

@retronym
Copy link
Member Author

retronym commented Dec 1, 2013

We're tantalizingly close to having nightly builds that will catch this.

Overloading and source compatibility is a bit of a minefield.

@som-snytt
Copy link
Contributor

LGTM. I'll study why 2.11 is not carte blanche on compatibility.

adriaanm added a commit that referenced this pull request Dec 2, 2013
SI-8022 Backwards compatibility for Regex#unapplySeq
@adriaanm adriaanm merged commit 6c63ab1 into scala:master Dec 2, 2013
@adriaanm
Copy link
Contributor

adriaanm commented Dec 4, 2013

Because we want people to upgrade. Recompiling is about all you can ask for. (And compiling with deprecations as fatal warnings.)

@retronym
Copy link
Member Author

retronym commented Dec 4, 2013

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

@som-snytt
Copy link
Contributor

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.

@retronym
Copy link
Member Author

retronym commented Dec 4, 2013

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.

@som-snytt
Copy link
Contributor

BTW, touching on consistency,

scala> Groups unapplySeq ("a(b)c".r findFirstMatchIn "abc").get
res1: Option[Seq[String]] = Some(Vector(b))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants