Pith. sign in

REVIEW 3 major objections 5 minor 20 references

Scala Implicits are Everywhere: A large-scale study of the use of Implicits in the wild

T0 review · 3 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Implicit parameters and implicit conversions are not a niche Scala feature: a 7,280-project corpus shows they appear at 27.2% of all call sites and in 98.2% of projects.

desk verdict A credible first large-scale measurement of Scala implicits; the pervasiveness result holds, but the headline call-site ratio needs validation and the compile-time claims need tempering. read the letter →

arxiv 1908.07883 v3 pith:IEIPNJ4U submitted 2019-08-21 cs.PL cs.SE

Filip Křikava , Heather Miller , Jan Vitek This is my paper · ORCID
classification cs.PLcs.SE
keywords Scalaimplicitparametersconversionscall-siteanalysiscorpusstudytypeclassescompile-timeoverheadlanguagedesign
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper sets out to show that Scala's implicits—the compiler filling in missing arguments and silently applying type conversions—are a near-universal, load-bearing part of real Scala programs, not an advanced corner of the language. Using a corpus of 7,280 buildable, deduplicated Scala projects, it reports that 98.2% of projects contain at least one implicit-involving call site, that 78.2% declare at least one implicit definition, and that about 27.2% of all call sites involve implicit resolution. It also documents which idioms dominate (type classes and extension methods above all) and reports that the density of implicit call sites correlates with slower compilation. The stakes are concrete: proposed changes to Scala's implicit mechanisms would touch nearly every codebase in the corpus, including 16.2% of projects that would break if unrelated implicit conversions were removed.

What carries the argument

The argument rides on a semantic compiler plugin that records 'synthetic trees'—trees the compiler inserts during type checking, such as the hidden executor argument in Future(1) and the injected conversion in 'just like magic!'.enEspanol. Because implicit calls leave little trace in the original source text, syntactic scanning cannot see them; the plugin's record of injected code is what lets each call site be matched to its defining declaration. The pipeline then classifies declarations into idioms—conversions, parameters, type classes, extension methods, contexts, type proofs—and aggregates them across the deduplicated corpus, separating application code, library code, and tests.

What would settle it

Re-run the same analysis on the projects the pipeline discarded—those that failed to compile or used other build tools—and check whether the 27.2% call-site ratio and the 98.2% project-level usage rate survive; if a large share of those projects show near-zero implicit use, the universality result is an artifact of the buildable subset.

Watch

Extended reading notes

Core claim

In the paper's own terms: implicits are the most used feature of Scala. Across 7,280 projects with 18.7M lines of code, 98.2% of projects have at least one call site resolved through implicits, 78.2% define at least one implicit value, and 27.2% of all call sites involve implicit resolution, which amounts to 8.1M of 29.6M call sites and 370.7K implicit declarations. Implicit parameters account for 60.3% of these call sites and conversions for the rest, with tests using implicits at roughly twice the rate of application code. The paper classifies the dominant idioms—type classes are the most widely declared and used pattern, followed by extension methods and contexts—and measures a compile-time penalty that grows with implicit density. It concludes that any future design of implicits should limit expressivity to improve comprehensibility and that tooling must agree with the compiler on how resolution works.

Load-bearing premise

The entire study depends on the sample being representative: the 7,280 projects that could be compiled with one build tool and a narrow range of Scala versions stand in for all Scala code in the wild, including projects that failed to build or used other build setups.

Editorial extensions

If this is right

  • Any language change that alters implicit resolution—restricting conversions, changing scope priority, or renaming resolution mechanics—has a wide blast radius: 98.2% of projects use implicits and 78.2% define them.
  • Deprecating unrelated implicit conversions, a change already discussed in the Scala community, would break 1.2K projects (16.2%) in this corpus.
  • Because 27.2% of call sites depend on implicit resolution, compiler and IDE implementations that disagree about resolution will mislead a large share of users; the corpus gives a baseline for testing such divergence.
  • Compile-time optimization of implicit resolution deserves priority: the data show compilation speed falling as implicit call-site density rises, with type-class use compounding the effect.
  • Testing code is the densest implicit user, so test frameworks and test code are the first place to expect readability and tooling problems.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If Scala's next compiler ships with a new implicit design, this corpus suggests the migration tools should prioritize type classes, extension methods, and context parameters, since those three idioms account for most declarations and call sites.
  • The compile-time correlation suggests a concrete experiment the paper does not run: instrument a set of these projects with a resolution cache or a restricted search scope and measure whether compilation speed improves by the amount the density curve would predict.
  • The finding that tests use implicits roughly twice as often suggests that usability studies of implicit-heavy APIs should recruit test-code authors, whose experience may differ from library implementors'.
  • A tool that visualizes injected implicit calls at each call site could be evaluated against this corpus by checking whether it reduces the time programmers take to explain the injected-code cases such as the 5,695-argument type-level example.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper reports a large-scale empirical study of implicit parameters and implicit conversions in Scala. The authors build an automated pipeline that clones GitHub projects, filters to Sbt-based projects with compatible Scala versions, deduplicates them, compiles them with a Scalameta/SemanticDB plugin, and extracts implicit declarations and call sites. On a final corpus of 7,280 projects (18.7M lines of Scala code), the paper reports that 98.2% of projects use implicits, 78.2% define implicit declarations, and about 27.2% of call sites involve implicit resolution. It also classifies implicit idioms (conversions, type classes, contexts, type proofs, etc.), measures the complexity of injected implicit arguments, and analyzes the relationship between implicit density and compilation speed. The artifact is publicly available, and the paper explicitly documents corpus construction steps and failure rates.

Significance. If the headline figures are correct, this is the first large-scale quantitative demonstration of how pervasive Scala implicits are, with direct relevance to language design (e.g., Scala 3's redesign of implicits) and tooling. The pipeline is a reusable, open-source artifact, and the paper is transparent about corpus construction, compilation failures, and the limitations of Scalameta. The reported statistics are derived from a defined pipeline rather than from fitted constants or tuned targets, so the circularity risk is low. The main gaps are the absence of validation of the SemanticDB-based extractor and the lack of rigorous statistical support for the compile-time claims; both are addressable within the scope of the manuscript.

major comments (3)
  1. [§3.1, §5] The headline figures—98.2% of projects using implicits and 27.2% of call sites involving implicit resolution—are produced by a custom extractor over SemanticDB synthetic trees, but the paper reports no precision/recall validation of this extractor and never defines the denominator '29.6M call sites (explicit and implicit combined)' operationally. SemanticDB includes synthetic call sites and injected parameters that do not appear in source (Section 3.1), and Section 5.6 discloses that 3% of implicit uses have unresolvable symbols. Without a ground-truth sample (e.g., a manually inspected set of projects or a comparison with scalac's -Yshow-implicit output), the central claim that 'one out of every four call sites' uses implicits could be an artifact of what SemanticDB counts as a call site. This is load-bearing and should be addressed with a validation study and a precise definition of the denominator.
  2. [§5.5, Figure 11] The compile-time claim in Section 5.5 and Figure 11 is supported only by loess curves with no confidence intervals, significance tests, or confounder control. The two groups compared in Figure 11 differ in size (1,969 vs. 488 projects) and in total lines of code (8.4M vs. 2.8M), and the metric 'lines per second' can be affected by project size, dependency count, compiler version, and compilation settings. The statement that 'the cost of compilation increases with the density of implicits' is therefore not established by the presented analysis. The authors should either add a regression or sensitivity analysis with appropriate controls and uncertainty quantification, or weaken the claim to a description of the observed trend.
  3. [§4, §5.6] The corpus is restricted to Sbt-based projects on specific Scala versions that compile, and the pipeline shrinks the initial 65,177 projects to 11,057 and then to 7,326 projects that build successfully. Section 5.6 acknowledges that findings may not generalize to industrial code, but the title and conclusions speak to implicits 'in the wild.' Because the central prevalence figures could shift if excluded projects (other build systems, older Scala versions, or failing builds) use implicits differently, the paper should quantitatively compare included and excluded projects on observable attributes (e.g., project size, star counts, dependency structure) or restrict the conclusions to the analyzed corpus. This is an external-validity concern that is disclosed but not yet quantified.
minor comments (5)
  1. [Abstract, §5.2] The abstract reports '370.7K implicit declarations,' while Section 5.2 reports 'over 370.7K implicit parameter declarations'; the terminology should be made consistent.
  2. [§5, Figure 7] The paper reports both an overall ratio of 27.2% of call sites and a per-project median of 23.4% (Figure 7); the text should clarify which quantity is used in each summary statement.
  3. [§5.2] The sentence 'Calls sites with implicit parameters are frequent, they account for 46.2% (3.7M) of all Scala call sites' is ambiguous about whether 'all Scala call sites' includes implicit conversion call sites and synthetic trees; this should be defined precisely.
  4. [§4] There is a typo: 'Graddle' should be 'Gradle.'
  5. [§5.5] The relationship between the 1,969 projects with compiler statistics and the 488 projects using shapeless is not stated; the potential overlap should be reported to help interpret the comparison.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: the prevalence figures are direct measurements over a defined corpus with no fitted parameters or self-referential derivation.

full rationale

The paper's claims are empirical counts over a fixed corpus; no quantity is defined in terms of the result it is supposed to establish. The headline figures (98.2% of projects using implicits, 78.2% defining them, and 27.2% of call sites involving implicit resolution) are produced by an extraction pipeline over SemanticDB synthetics described in Sections 3.1 and 5. The call-site ratio is simply 8.1M implicit call sites divided by 29.6M total call sites; neither the numerator nor the denominator was fitted or adjusted to yield the reported percentages. The deduplication thresholds in Section 4 were hand-tuned to keep original projects while discarding copies, not to produce prevalence numbers, so no target result is encoded into the corpus construction. The only self-citation that could be noted is the use of the DejaVu duplicate filter [Lopes et al. 2017], whose author list overlaps with the present paper; however, this is a reusable external tool used for corpus deduplication and is not the evidentiary basis of the implicit-usage measurements. The paper itself discloses internal-validity limitations in Sections 3 and 5.6: Scalameta supports only certain Scala versions, white-box macros are unsupported, 3% of implicit uses had unresolved symbols, and 3,731 projects failed to build. These are genuine threats to measurement validity and external generalizability, but they are not circular reductions: no equation, fitted constant, or self-referential uniqueness claim is invoked anywhere in the derivation chain. The study is therefore self-contained as a measurement study and receives a circularity score of 0.

Assumptions & free parameters 2 free parameters · 3 assumptions · 0 invented entities

This is an empirical study, so there are no mathematical free parameters in the classical sense. The hand-set thresholds for corpus construction and the reliance on SemanticDB synthetic trees are the main assumptions that the reported percentages rest on. The claims are prevalence statements conditional on this corpus.

free parameters (2)
  • Duplicate exclusion thresholds = 75% and 80% file duplication; >5 or >500 stars; >1 commit; active >2 months
    Chosen experimentally in Section 4 to discard duplicate projects while keeping originals. These thresholds directly determine which projects enter the analyzed corpus, so all prevalence percentages are conditional on them. No sensitivity analysis is provided.
  • Small/large application LOC cutoff = 1,000 LOC
    Section 4 labels projects with fewer than 1,000 LOC as small apps. The cutoff is arbitrary and affects all category-level statistics, though the headline '98.2% of projects use implicits' does not depend on it.
assumptions (3)
  • domain assumption SemanticDB synthetic trees faithfully capture every implicit parameter injection and implicit conversion performed by the compiler.
    Section 3.1 explains that the extractor relies on synthetic trees produced by Scalameta and scalac. If some implicit applications are not materialized in SemanticDB, all counts understate usage.
  • domain assumption The analyzed subset (Sbt-only, Scala 2.11.9+ or 2.12.4+, successfully compiled, deduplicated) is representative of the Scala ecosystem.
    Section 4 and Section 5.6 describe the reduction from 65,177 projects to 7,280 and acknowledge that findings only generalize if the compiled subset represents broader Scala use. This is the main external-validity premise.
  • domain assumption Test code and generated code measure the same 'use of implicits' as production code.
    The corpus includes 5.9M lines of tests and 2.2M lines of generated code. Tests show much higher implicit call-site ratios (38% versus about 17% for applications), so including them affects aggregate percentages.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Scala Implicits are Everywhere: A large-scale study of the use of Implicits in the wild." pith.science (2026). https://pith.science/paper/IEIPNJ4U

@misc{pith2026190807883,
  author       = {Pith},
  title        = {Pith review of: Scala Implicits are Everywhere: A large-scale study of the use of Implicits in the wild},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IEIPNJ4U}},
  note         = {Machine review of arXiv:1908.07883}
}
read the original abstract

The Scala programming language offers two distinctive language features implicit parameters and implicit conversions, often referred together as implicits. Announced without fanfare in 2004, implicits have quickly grown to become a widely and pervasively used feature of the language. They provide a way to reduce the boilerplate code in Scala programs. They are also used to implement certain language features without having to modify the compiler. We report on a large-scale study of the use of implicits in the wild. For this, we analyzed 7,280 Scala projects hosted on GitHub, spanning over 8.1M call sites involving implicits and 370.7K implicit declarations across 18.7M lines of Scala code.

Figures

Figures reproduced from arXiv: 1908.07883 by the authors.

Figure 1
Figure 1. Implicits usage across our corpus of selecting and passing arguments to functions and converting between types to the compiler. For example, the enEspanol method from above uses an implicit parameter to get a reference to a service that can do the translation: def enEspanol(implicit ts:Translator):String. Calling a function that has implicit arguments results in the omitted arguments being filled from the context of… view at source ↗
Figure 2
Figure 2. Instead of injecting a conversion to intToCard (1), the compiler injects deck.apply (2) since List[A] extends (transitively) Function[Int,A]. An exception is thrown because the deck contains only one element (http://scalapuzzlers.com/) operation that should have been done on the original object.1 Another project reported a 56 line file taking 5 seconds to compile because of implicit resolution. Changing one line of … view at source ↗
Figure 3
Figure 3. Type classes a generic type class instance that combined with an instance of type Show[T] returns a type class instance of type Show[List[T]] (Fig. 3c). Thus, a call to show(List(Shape(3), Shape(4))) is transformed to show(List(Shape(3), Shape(4)))(listShow[Shape](shapeShow)), with two levels of implicits inserted. This implicit type class derivation is what makes type classes very powerful. The mechanism can be fur… view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: Type class derivations automated solution, does not require extra code at the client side beside importing its machinery (cf. Listing. 4c). Compile time is affected by the choice of approach; taking the manual as a base line, semi-automated is 2.5x slower and automated…
Figure 5
Figure 5. Figure 5: Scala Analysis pipeline. (1) is the size of source code, (2) is the size of source plus compiled code and [PITH_FULL_IMAGE:figures/full_fig_p010_5.png]
Figure 6
Figure 6. Figure 6: Corpus overview From the resulting 11,057 projects, we were able to successfully compile 7,326 projects. 3,731 projects failed to build. We follow the standard procedure of building Sbt projects. If a project required additional steps, we marked it as failed. The follo…
Figure 7
Figure 7. Figure 7: shows for each category a distribution of implicit call site ratios. The box is the 25th/75th percentiles and the line inside the box represents the median with the added jitters showing the actual distribution. For applications and libraries, the median is similar. It…
Figure 8
Figure 8. Figure 8: Origin of parameter declarations Proc. ACM Program. Lang., Vol. 3, No. OOPSLA, Article 163. Publication date: October 2019 [PITH_FULL_IMAGE:figures/full_fig_p016_8.png]
Figure 9
Figure 9. Figure 9: Injected arguments 34.1%47.2% 10.7% 3.2% 1.2% 0.7% 0.5% 0.3% 0.2% 0.2% 0.1% 1,000 10,000 100,000 0 1 2 3 4 5 6 7 8 9 10 Number of implicit parameters Number of declarations (log) [PITH_FULL_IMAGE:figures/full_fig_p024_9.png]
Figure 11
Figure 11. Figure 11: Compilation slowdown Proc. ACM Program. Lang., Vol. 3, No. OOPSLA, Article 163. Publication date: October 2019 [PITH_FULL_IMAGE:figures/full_fig_p025_11.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

20 extracted references · 9 canonical work pages

  1. [7]

    DéjàVu: a map of code duplicates on GitHub. Proc. ACM Program. Lang. 1, OOPSLA. https://doi.org/10.1145/3133908 Chris Marshall

    doi:10.1145/3133908

  2. [9]

    In Cconference on Object Oriented Pogramming Systems Languages and Applications (OOPSLA)

    Instant Pickles: Generating Object-oriented Pickler Combinators for Fast and Extensible Serialization. In Cconference on Object Oriented Pogramming Systems Languages and Applications (OOPSLA). https://doi.org/10.1145/2509136.2509547 Heather Miller, Philipp Haller, and Martin Odersky

    arXiv

  3. [10]

    PACMPL 2, POPL

    Simplicitly: foundations and applications of implicit function types. PACMPL 2, POPL. https://doi.org/10.1145/3158130 Martin Odersky and Adriaan Moors

    doi:10.1145/3158130

  4. [11]

    In Foundations of Software Technology and Theoretical Computer Science (FST TCS)

    Fighting bit rot with types (experience report: Scala collections). In Foundations of Software Technology and Theoretical Computer Science (FST TCS) . https://doi.org/10.4230/LIPIcs.FSTTCS.2009.2338 Bruno Oliveira C. d. S., Adriaan Moors, and Martin Odersky

    work page arXiv 2009

  5. [16]

    Journal of Functional Programming https://doi.org/10.1017/s0956796818000242 Joshua D Suereth

    Cochis: Stable and Coherent Implicits. Journal of Functional Programming https://doi.org/10.1017/s0956796818000242 Joshua D Suereth

    work page doi:10.1017/s0956796818000242

  6. [17]

    https://web.archive.org/web/20170922191333/https://docs.scala-lang.org/overviews/ core/implicit-classes.html

    Implicit Classes. https://web.archive.org/web/20170922191333/https://docs.scala-lang.org/overviews/ core/implicit-classes.html. Ole Tange et al

    work page arXiv

  7. [18]

    In European Conference on Object-Oriented Programming (ECOOP)

    Why Do Scala Developers Mix the Actor Model with other Concurrency Models?. In European Conference on Object-Oriented Programming (ECOOP) . https://doi.org/10.1007/978-3- 642-39038-8_13 Eric Torreborre

    doi:10.1007/978-3-

  8. [163]

    Publication date: October 2019

    2019

Show all 20 references
  1. [1989]

    In Symposium on Principles of Programming Languages (POPL)

    How to Make ad-hoc Polymorphism Less ad-hoc. In Symposium on Principles of Programming Languages (POPL). https://doi.org/10.1145/75277.75283 Proc. ACM Program. Lang., Vol. 3, No. OOPSLA, Article

  2. [1991]

    Theoretical Aspects of Computer Software https://doi.org/10.1007/3-540-54415-1_70 Arjen Rouvoet

    The coherence of languages with intersection types. Theoretical Aspects of Computer Software https://doi.org/10.1007/3-540-54415-1_70 Arjen Rouvoet

    doi

  3. [2000]

    In Symposium on Principles of Programming Languages (POPL)

    Implicit Parameters: Dynamic Scoping with Static Types. In Symposium on Principles of Programming Languages (POPL) . https://doi.org/10.1145/325694.325708 Lightbend

  4. [2006]

    Conference on Generative Programming and Component Engineering (GPCE)

    Software extension and integration with type classes. Conference on Generative Programming and Component Engineering (GPCE) . https://doi.org/10.1145/1173706.1173732 Jeffrey R. Lewis, John Launchbury, Erik Meijer, and Mark B. Shields

  5. [2009]

    com/questions/1722726/is-the-scala-2-8-collections-library-a-case-of-the-longest-suicide-note-in-hist

    Is the Scala 2.8 collections library a case of the longest suicide note in history? https://stackoverflow. com/questions/1722726/is-the-scala-2-8-collections-library-a-case-of-the-longest-suicide-note-in-hist. Heather Miller, Philipp Haller, Eugene Burmako, and Martin Odersky

  6. [2010]

    In Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA)

    Type classes as objects and implicits. In Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA) . https://doi.org/10.1145/1869459.1869489 Bruno Oliveira C. d. S., Tom Schrijvers, Wontae Choi, Wonchan Lee, and Kwangkeun Yi

  7. [2012]

    In Conference on Programming Language Design and Implementation (PLDI)

    The implicit calculus: a new foundation for generic programming. In Conference on Programming Language Design and Implementation (PLDI) . https://doi.org/10.1145/2254064.2254070 Andrew Phillips and Nermin Serifovic

  8. [2013]

    In Working Conference on Mining Software Repositories (MSR)

    The GHTorrent dataset and tool suite. In Working Conference on Mining Software Repositories (MSR) . https://doi.org/2487085.2487132 Li Haoyi

  9. [2015]

    In European Conference on Object-Oriented Programming (ECOOP)

    The Good, the Bad, and the Ugly: An Empirical Study of Implicit Type Conversions in JavaScript. In European Conference on Object-Oriented Programming (ECOOP) . https://doi.org/10.4230/LIPIcs.ECOOP. 2015.519 John C. Reynolds

    2015 doi

  10. [2016]

    https://web.archive.org/web/20180326160306/http://www.lihaoyi.com/ post/ImplicitDesignPatternsinScala.html

    Implicit Design Patterns in Scala. https://web.archive.org/web/20180326160306/http://www.lihaoyi.com/ post/ImplicitDesignPatternsinScala.html. Joeri De Koster

  11. [2017]

    Unification of Compile-Time and Runtime Metaprogramming in Scala. (2017). https://doi.org/10. 5075/epfl-thesis-7159 Jorge Vicente Cantero

    2017

  12. [2019]

    In International Conference on Mining Software Repositories (MSR)

    Assessing Diffusion and Perception of Test Smells in Scala Projects. In International Conference on Mining Software Repositories (MSR) . https://doi.org/10.1109/MSR.2019.00072 Georgios Gousios

    2019

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.