Handle long type parameter lists

[emchristiansen]

First, thanks for developing Scalariform. I use it hundreds of times a day.

The issue: I code in an extremely functional style, and often have very long type parameter lists. For example, this is a function signature from my code:

def relativeBenchmark[E <% RuntimeConfig => ExperimentRunner[R], R <% RuntimeConfig => ExperimentSummary](experiment: E): Double

Scalariform, used from Eclipse, tries to put all the type parameters on one line, meaning the above signature would extend beyond the 80 character mark.

Ideally: Please detect when a type parameter list is long and distribute it across multiple lines. I like this format:

def relativeBenchmark[
E <% RuntimeConfig => ExperimentRunner[R],
R <% RuntimeConfig => ExperimentSummary](experiment: E): Double

I'd be happy with: Don't format type parameter lists that extend across multiple lines.

[sirthias]

+1

Also, if the method has several parameter lists the formatter currently puts them all on one line, even if I manually
distributed them across several lines, which is annoying.

So:

def foo(x: Int)
          (y: Int): Int = ...

is always reformatted to

def foo(x: Int)(y: Int): Int = ...

whereas

def foo(x: Int,
        y: Int): Int = ...

is kept as is (or even properly aligned).

[ochafik]

+1

The problem only gets worse with widespread private[this] usage. I'm not using scalariform in Scalaxy/Streams because I'm fond of the following style:

  private[this]
  def bar[A <: Foo : Bar,
          B : Baz : Bam]
         (x: A, y: B)
         (implicit z: Int)
         : Foo = ???

instead of:

  private[this] def bar[A <: Foo : Bar, B : Baz : Bam](x: A, y: B)(implicit z: Int): Foo = ???

[cvogt]

+1
Here is my favorite variant:

  private[this]
  def bar
    [A <: Foo : Bar, B : Baz : Bam]
    (x: A, y: B)
    (implicit z: Int)
    : Foo
    = ???

[sergius]

+1
Long type parameter list suggested by @emchristiansen.
Any progress in this regard since 2013? 😄

[hawkw]

I'd also really like to see this feature, and I'd be willing to open a PR to implement it myself. However, I could use a few pointers from a maintainer with regard to where to start in the codebase, if anyone's willing to point me in the right direction.

[godenji]

@hawkw

At a glance it looks like a quick and dirty proof of concept could be achieved by disabling formatting on this line. i.e. change to NoFormatResult

Then create an executable jar to test whether or not sample scala file containing various long type paramater lists leaves applicable code blocks unformatted.

If that works we can look into creating a new Preference Descriptor that allows users to opt-in to type parameter list formatting.

[godenji]

This is fixed in 0.2.4

To enable the below formatting style set either AllowParamGroupsOnNewlines or allowParamGroupsOnNewlines to true in your build.sbt/.scalariform.conf file.

def foo[T]
  (a: A)
  (b: B)
  (implicit t: T)

Note that this does not automatically format sources to the desired format, but rather prevents the default behavior of collapsing param groups into a single line.

Also, type params can be placed on a newline, but unlike paren groups, a bracket group spanning multiple lines collapses to a single line (sorry, bracket handling code is seriously hairy).