Giters

scala / scala-parallel-collections

Parallel collections standard library module for Scala 2.13+

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Subtle dangers of bincompat violation

NthPortal opened this issue · comments

commented

This module accesses several private[<pkg>] definitions in the standard library, and in ways or places that are not well documented. Changes to definitions in the standard library, or to usage in this module, could then lead to bincompat violations of two types:

  1. The accessibility of a definition in the standard library that is used in this module is accidentally restricted during refactoring by someone who does not realise it is used outside of the standard library. For example, s.c.m.ArrayBuffer#array is private[collection], but is only accessed from within mutable in the standard library. If someone decides to tighten the encapsulation and change it to private[mutable], this module will no longer compile, making what is normally an acceptable standard library change a bincompat violation instead. This type of bincompat violation would become visible within this module as soon as the Scala version of this module is upgraded.
  2. A private[<pkg>] definition is added to the standard library in 2.13.1+, and someone changes this module to use it, not realising that it was not available in all 2.13.x versions. This violates bincompat subtlely in a way that will only be visible to downstream users, and never to this module.

@SethTisue commented that the team was aware of the concerns about the first type of bincompat violation when this module was separated from the standard library, but that they felt there were only bad options. So while accessing private[<pkg>] definitions from the standard library was not ideal, it was accepted as a necessary compromise to separate the module. However, the community build is a backstop to help prevent the first type of bincompat violation from making it into a release, as this module would fail to compile within the community build.

Unfortunately, the community build will not be able to detect the second, more subtle type of bincompat violation. Seth suggested that perhaps this module's scalaVersion should be left at 2.13.0, to prevent the use of added methods (because from this module's perspective, they won't have been added).

commented

this discussion happened on discord, and Seth suggested opening a ticket to have a good record of the discussion, if nothing else