Dear Community
We from the Scala team at Lightbend have decided to take some time this summer to work on usability improvements that are always falling through the cracks while we're busy working on the hard features of the next Scala release. Here is a summary of our project proposals.
@som-snytt already implemented the JLine 3 upgrade (scala/scala#8036) which gives multi-line history and editing. We are planning to add further improvements (many of them pioneered by Ammonite and/or the Dotty REPL) on top of this, for example syntax highlighting and import library dependencies.
Ticket: scala/scala-dev#325
Lead: @adriaanm
Most people obtain and use Scala through the build tool, but we still build a distribution archive. Using the distribution has a few shortcomings:
- need to install every new version
- sbt is not included
- no simple method to add library dependencies
We propose to stop building the distribution and instead provide version-agnostic scripts to run the various tools that make up Scala (REPL, sbt).
Ticket: scala/scala-dev#326, https://github.com/lightbend/scala-team/pull/113
Lead: @dwijnand
We would like to work together with the community and maintainers of testing libraries to provide a zero-dependency unit testing library that ships with Scala releases, i.e., not as an external dependency. This library will be used in core projects (Scala, Scala.js) that currently have to fall back on JUnit. We also hope to find a common path forward to overcome some of the fragmentation in testing styles and libraries that is currently present in the Scala community.
Ticket: https://github.com/lightbend/scala-team/pull/110
Lead: @eed3si9n
There are situations where conditional compilation would be quite handy, for example when cross-building a project against multiple Scala versions. This proposal introduces a preprocessor into the Scala compiler so that no changes to the build toolchain is required.
Ticket: https://github.com/lightbend/scala-team/issues/112
Lead: @szeiger
The Scala compiler issues helpful warnings, for example when comparing unrelated types. Additional checks and warnings can be enabled with -Xlint, the -Werror flag turns all warnings into errors. In reality, not all warnings can always be eliminated: for example, cross-building may require using a deprecated API. This proposal introduces compiler flags to selectively promote or silence compiler warnings. It also adds support for suppressing warnings locally.
Ticket: https://github.com/lightbend/scala-team/issues/116
Lead: @lrytz
The projects listed above are being discussed on their respective scala-dev ticket. As always, we welcome and encourage contributions and feedback.
If you have a usability project in mind that is not being discussed currently, feel free to mention it here. And of course, we'd be thrilled if you're motivated to join the usability summer with your own project!