You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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).
The text was updated successfully, but these errors were encountered:
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:s.c.m.ArrayBuffer#array
isprivate[collection]
, but is only accessed from withinmutable
in the standard library. If someone decides to tighten the encapsulation and change it toprivate[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.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).The text was updated successfully, but these errors were encountered: