There is a related syntax speed bump, about commas in indentation in parens, which has a PR but no feedback. That was an exercise in what to allow (or encourage) under what rule.
Tangentially, there is a ticket on Scala 2 about whether to tolerate empty parens with traits. I assumed incorrectly that Scala 3 would be strict (because traits have params). I don’t know whether that PR will progress, but the syntax I decided to allow was Java-style new T() {}, because I found several usages, and because one can argue that the parens belong to the anonymous class.
That is some wild multi-parenting.
Someone asked about adapting to Java classes with multiple constructors, with the answer that you wind up with multiple anonymous classes.
Now I’m less willing to relinquish the syntax.
My previous foray into finely sliced traits, besides collections, was with reporter functionality, but that was mostly reverted, supposedly because I went overboard with it. But can one have too much of a good thing one is passionate about?
Erm, if you mean that having anonymous class instantiation with multi-parenting is a good thing taken to excess (ahem), then I’d welcome an alternative that is as least as pithy.
What I’m usually doing with this is to mix-in contract checking traits, where the contracts are expressed as abstract overrides; the idea being to do a before-and-after wrapping around the methods in the first trait / class. I generally don’t want these contracts in production code but do want them in tests, hence the use of mixing-in - and I can use this trick with several competing implementations of the same trait.
In Java-land I use Spring’s AOP support to do this; pithy it is not, though.
Anyway, thought I’d register my support for two complementary workarounds if with is dropped (or for that matter, is kept but restricted for the sake of consistency with the comma).