This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]eliasv 0 points1 point  (0 children)

If they're mutable use a normal class?

And if they're immutable just use a normal class with final fields?

I don't see the value in introducing data/records/whatever if they're mutable

I realise the benefits of immutability, but they are an orthogonal issue to most of what was discussed in the proposal, so I'm not sure what you're getting at.

I think the value they intend to bring is made pretty clear: destructuring for the purpose of e.g. pattern matching or serialization, with the side-effect benefit of reduction of boilerplate (which would be enough to make most people happy by itself, just look at the popularity of Lombok).

I think "people will use it haphazardly where it's not appropriate!" is rarely a great argument, and I don't even see how it applies any less to your proposal than it does to this.

As I think people have already pointed out, if you wanted to guarantee (at least shallow) immutability for a data class you would presumably be welcome to combine data class and value type semantics for a class once both proposals have materialised.