I’m tentatively opposed, as I see the arguments of both sides as equal and negating one another, making the change a neutral net worth.
IMO, @jducoeur’s and @tarsa’s argument is the strongest argument in favor of the change – preventing developers from abusing case classes just because they provider new-less constructors.
On the other hand, I find @nafg’s and @morgen-peschke’s opposing arguments important as well – signal, not noise; blurring the distinction between regular and case classes; real work in constructors.
@Ichoran I am very much in the opinion that the new keyword has a purpose of reminding people of things they do need to be reminded about. Well, perhaps need is a strong word in this case, but I do think the keyword is not without significance.
new tells me that I am constructing a non-value class, that has non-trivial methods that my current unit is dependent on. In many cases, I would like to be able to mock this new class when testing my unit, and I can do this only if I inject said new class into my unit (via constructor or method argument).
This is more eloquently described by Miško Hevery (already referenced in this thread) in his general post on Writing Testable Code and the more specific one about How to Think About the “new” Operator with Respect to Unit Testing.
If I may, I’d like to add another idea into the pile. How about an additional keyword / annotation that will make the compiler automatically generate an apply method?
@Apply
class MyLovelyFoo(bar: Bar)
// or
apply class MyLovelyFoo(bar: Bar)
// or
class apply MyLovelyFoo(bar: Bar)
This could help prevent the abuse of case classes for the sake of new-less constructors for those who do not care for the distinction between the types of classes or the significance of the keyword, while still allowing class authors who care about these things keep the distinction and the explicit constructors.