What are the implications of not implementing FunctionN? Will the apply method still be there? Can I still pass the case class companion object to a higher order function? Will shapeless' Iso.hlist still work? (that's the big one really, as it allows dealing with case classes more-or-less generically)

Yes the apply method is still there. But since it has more than 22 arguments, you cant't lift it into a function object anymore.

This will break some tools, like Play's forms, that need you to pass to a couple of serialization/deserialization functions.

Shapeless will probably be fine, or at least, since it is macro based, it will be able to go around the missing unapply and extract the fields directly, like pattern matching does. (I don't know shapeless enough to go into more details)

Aaaaah, interesting. Spray uses Shapeless heavily, so this should make it a shoo-in for the Typesafe stack.

This will be an interesting side effect: "omit generation of unapply"

Yes, this means there won't be a 1-to-1 conversion between a case class and a tuple anymore, since tuples are still limited to 22. This will probably break a few things out there (for people crazy enough to use case classes with 23+ parameters).

The problem is the real world doesn't always leave you with a choice. If you need to interface with a database that's got a table with 43 columns, good luck using Slick. Need to serialize it to JSON? Play-Json isn't going to like that.

I'm very much looking forward to fixing this ridiculous situation. Onboarding a new hire to Scala with this being the first thing they run in to isn't pretty.

Have to agree.. I ran into this when on the first time using Scala ,when I thought it would be fun to learn the language and a framework at the same time (Play). After initial crying for a bit I gave up trying to reason why this limit was put in place and just nested my data structure.

It's a problem that I contemplate every day. More often than not I have to resolve to using Map in which case I have to use external JSON library, because like you mentioned - Play JSON is not that friendly with anything else than case class.

We've resorted to an ugly nested case class structure. We like Play-Json overall, it works well even with large (>100mb) JSON objects, but we'd love to not deal with that. TBH, it's a bigger problem with Slick where you we can't just mess with the schema since other systems use the same DB.

"We've resorted to an ugly nested case class structure."

Yes the same here, and I haven't found an idea that's overall better, taking everything into account.

I think the only place I've seen anyone wanting more than 22 parameters was people who had a database table with more than 22 rows (!) and where using the SLICK library.

Yeah we ran into this problem... Scala and the whole ecosystem can get annoying. In the real world, outside of the academic bubble that Scala lives in, database tables are over 22 columns.

In Scala I find it more natural to group multiple columns together / break the case-class representing the table into multiple case-classes. The problem is that Slick needs to serialize/deserialize those case-classes into tuples.

I think the arity limit is more or less planned to be fixed in Scala > 2.11 anyway.

Seems to be fixed in v2.0: http://slick.typesafe.com/news/2014/01/21/slick-2.0.0-releas...

You can also run into it with forms in play, although for a variety of reasons you hit it at 18.

The whole situation just drips with arrogance... "we have a magic number, and if you hit it, you suck"

I agree. I know people posted a comment saying its fixed in 2.11 but if Scala wants to be production ready language it shouldn't take 10 years to address this.

> "we have a magic number, and if you hit it, you suck"

You mean like Java does since ... forever?

So basically, anyone with a legacy database :)