Skip to content
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

Subtle dangers of bincompat violation #204

Open
NthPortal opened this issue Nov 19, 2021 · 1 comment
Open

Subtle dangers of bincompat violation #204

NthPortal opened this issue Nov 19, 2021 · 1 comment

Comments

@NthPortal
Copy link
Contributor

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).

@NthPortal
Copy link
Contributor Author

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

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

No branches or pull requests

1 participant