Skip to content

Drop the blanket Scala 2 caveat; report the real gap instead - #146

Open
rochala wants to merge 1 commit into
mainfrom
fix/scala2-caveat
Open

Drop the blanket Scala 2 caveat; report the real gap instead#146
rochala wants to merge 1 commit into
mainfrom
fix/scala2-caveat

Conversation

@rochala

@rochala rochala commented Aug 23, 2026

Copy link
Copy Markdown
Contributor

Problem #4 from the printer review, backed by a measurement rather than an impression.

The problem

printSymbolSignatureSafe appended // [Scala 2 — limited type information] to every Scala 2 signature, keyed on source language alone — never on evidence that anything was lost. It fires ~70 times in one cats.data.NonEmptyList lookup, including on def size: Int.

The measurement

Compared scala-library:2.13.16 (pickles) against scala2-library-tasty-experimental_3:3.7.4 — the same standard library in two encodings, so the pairing is exact.

2878 signature lines across 76 symbols. 95.4% byte-identical after normalisation. Zero cases where the Scala 2 side lost a type the Scala 3 side had.

Of the 132 differing lines:

Category Lines Worse side
Higher-kinded type args (SeqFactory[List] vs SeqFactory[[A] =>> List[A]]) 51 Scala 3
Synthetic $default$N accessors leaking 33 Scala 3
Empty param list (toString() vs toString) 19 Scala 3 (2.13 really declares ())
Implicit-class conversion defs dropped 22 Scala 2
Cosmetics 7 mixed

So Scala 2 renders better roughly 70 lines to 22 — and the one category where it loses is PublicApiFilter.isSyntheticSym dropping symbols, a filter bug a per-signature caveat does nothing about. The TASTy side also failed to load 5 of 81 symbols (None, Predef, AnyVal, Tuple2, SeqOps); the pickle side failed none.

What is actually missing

Documentation. Pickles carry no Scaladoc: 0 of 76 Scala 2 lookups had prose docs versus 70 of 76 from TASTy. Verified directly — cats.effect.IO prints its docstring, cats.data.NonEmptyList prints none.

The change

  • Delete the per-signature caveat.
  • Reword the once-per-response footer (GetHandler.warnScala2) to Note: Scala 2 artifact — documentation comments are not available. — true for 76/76, unlike the type claim.
  • Fix the README support table, which repeated the same inaccurate claim.

No per-signature predicate replaces it. If one is ever wanted, the defensible condition is language-independent — "the printer hit its fallback" — not "the source was Scala 2".

Verification

lib.test 372/372. The two IntegrationTest assertions on the stderr note still hold (the footer still mentions Scala 2, with accurate wording). The TypePrinterTest case that asserted the old caveat is updated to assert its absence plus the real signature.

Follow-ups this surfaced (not in this PR)

Verified against published artifacts, one PR each:

  1. Eta-expanded type lambdas — NonEmptyCollection[A, List, [A] =>> NonEmptyList[A]] where Scala 2 prints NonEmptyList; inconsistent within a single line.
  2. scala.jdk.CollectionConverters shows 20 class *HasAs* wrappers but 0 of the defs that attach them.
  3. scala.Char renders val MaxValue: with a raw U+FFFF and val MinValue: with a raw NUL into Markdown.

🤖 Generated with Claude Code

Every Scala 2 signature carried `// [Scala 2 — limited type information]`,
appended on source language alone rather than on any evidence of loss —
about 70 times in a single cats.data.NonEmptyList lookup.

Measured it. Comparing scala-library 2.13.16 (pickles) against
scala2-library-tasty-experimental_3 (the same stdlib recompiled to TASTy):
2878 signature lines over 76 symbols, 95.4% byte-identical after
normalisation, and no case where the Scala 2 side lost a type the Scala 3
side had. Where they diverge the Scala 2 rendering is the better one more
often than the worse (70 lines to 22), and the TASTy side is the one that
failed to load 5 of 81 symbols.

The real Scala 2 gap is documentation: pickles carry no Scaladoc, so 0 of
76 lookups had prose docs versus 70 of 76 from TASTy. So the per-signature
caveat goes, and the once-per-response footer now states what is true.

The README support table repeated the same inaccurate claim; corrected.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.

1 participant