Hacker News Reader

Comment by neverminder | Hacker News Reader

I wish the same was done for tuples, but it wasn't and it's unclear whether that's even in plans.

I'm not sure I understand the situations where having a tuple of that arity is beneficial. Some sort of code generation thing, perhaps?

Shouldn't that go hand in hand? The generated unapply method will involve a tuple of same arity I believe.

As the matter of fact I'm not sure now. I was looking for a confirmation that tuple limit is removed in Scala 2.11, but couldn't find it whereas statements that case class 22 parameter limit is removed are all over the place.

AbstractFunction, Function, Product and Tuple are all still limited to 22.

Increasing the limit would create too much bytecode, and in the current design, lifting the limit is just impossible (without runtime code generation or custom classloader, etc.).

So why did they choose to allow case classes to have arbitrary arity? Not that I'm complaining, I just don't understand the underworking of scala that well.

They just don't emit all the boilerplate which would require unlimited-arity Tuples/Functions/... for larger case classes.

film42: I think it was driven by Slick and the need to accommodate database tables with more than 22 columns

Indeed, because the fallback is HList and when I have tables up to 200 columns it's killing the CPU and crashing Scala IDE up to the point where you just can't work with it.

For that very reason, there is no generated unapply method for case classes with >22 parameters. This doesn't prevent pattern matching on the case class, because the patmat knows it is a case class and extracts the parameters directly, without calling unapply.

Reply on news.ycombinator.com