Wouldn't it be nice if functions extended Serializable and had generated equals/toString?

Question
1

I am not sure for the correct forum to post it, as it’s more an invitation to a discussion over an idea for a SIP.

  1. In functional code functions are ubiquitous. The fact that they are not serializable imposes a choice: either refrain from using functional style in implementation (favouring subclassing over passing functions) to avoid having them as fields, or make any object containing them somewhere in its subtree non serializable. Both seem rather big hits for essentially no reason I can see: being Serializable is on opt-in basis: any class containing the functions must explicitly extend it in order to be serializable, so there isn’t much risk of accidental leaking/serializing of large object graphs. Why not make functions serializable and let the user decide?

  2. Pattern matching is a common functional idiom, which in scala involves calls to equals. This method however is not overriden by any function class generated by the compiler, while it could: there is nothing preventing the comparison of all values in the closure and passed as the arguments to the synthetic method the function call is linked to. This makes inspecting objects difficult, requiring specialized workarounds and code aware of them in order to compare two functions.

  3. Debugging functional code in Scala, for example things like monadic composition, can be hell: it is often really hard in case of nested lambdas to know exactly in what function the control flow currently is. Similarly, printing objects which contain functions tells us nothing about what kind of functions they actually are. To alleviate it, I created my own function SAM subtype which accepts a name used in its toString, which are better than nothing and useful drop-ins for normal lambdas when debugging, but this has its shortcomings. Many if not lambdas are short and methods lifted to functions are also very common. It would be straightforward to implement toString as downright dump of the function body as it exists in the code, interpolating its argument(s) and values included in its closure. Method toString should not be used or depended upon for any purpose other than printing in the logs, so having a soft policy which overrides it only where code is short should not be an issue.

These can be implemented as macros (and I likely end up doing it), but would still require explicit calls to a factory method instead of simply using the function literal syntax. I agree that proposed behavior should not be enabled by default, but what about a compiler plugin requiring explict switching on or piggybacking on the scala.feature import functionality?