dart-lang / dart-lang/language
Should language versioning require opting in to non-breaking changes?
- Dominant language
- TeX
- Stars
- 2.9k
- Forks
- 239
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 14
Description
The strawman proposal for [per library versioning](https://github.com/dart-lang/language/blob/master/working/0093%20-%20Gradual%20Language%20Change%20Migration/0094%20-%20Per%20Library%20Language%20Version%20Selection/strawman.md) says
> Each package available to a program will have its own language version level associated (most likely specified in the `.packages` file). All libraries in that package will use that associated language level unless it declares a different level explicitly in the library.
>
> The `pub` tool configures this default language level for a package based on its SDK dependency. If a package requires an SDK of `^2.2.0`, it will default to the 2.2 language level.
>
> This means that a package cannot use features of a new SDK release without depending on that SDK release.
Is this the right choice for non-breaking changes?
On the plus side, if a package uses syntax which is not supported by the min SDK constraint, it should in fact get an error/warning.
On the minus side, this means that a package which does not use any new syntax will nonetheless start getting deprecation warnings when the supported lifespan of old language versions approaches, and then eventually will be rejected. The fix is easy: just bump the min SDK constraint forward. But it seems bad that code that is perfectly fine suffers from unnecessary procedural bit rot.
Perhaps we need to distinguish between "I am pinning myself to language version X" vs "I am compatible with everything from X to Y", where Y is the next breaking version release after X?
cc @lrhn @eernstg @munificent
Contributor guide
Assessment
This issue has not been assessed yet.