Currently, all fields in dataclasses can be frozen by passing frozen=True to the decorator. There are cases where it would be useful to have some fields be mutable, and others immutable. By using a strategy similar to how the decorator frozen works, using __setattr__ and __delattr__, it would be possible to support immutability per-field. This could perhaps be done by adding a frozen argument to the field constructor.

Can you explain your use case for this?

Also, how do you envision this working with the existing frozen, hashing, and equality behavior? There are a lot of interactions there, and we'd want to do something that makes sense holistically, and isn't likely to cause trouble for casual users.

I haven't checked, but does attrs do anything like this? It might make sense to try out the idea there, first.

A possible use case would be a field that represents an auto-incrementing database ID. Since the field is auto-incrementing in the database, it would be desirable to keep this field frozen, and others mutable once an instance of a data class is created. 

This is also a feature of data classes in other languages, for example Kotlin: https://kotlinlang.org/docs/reference/data-classes.html . The main difference here being that we don't have val and var, and thus mutability and immutability are harder to represent.

Hashing could be implemented such that frozen fields are allowed to be part of the hash, but unfrozen fields would remain only part of the hash when unsafe_hash is set. I believe equality follows from hashing, so the same rules should apply. 

The conflict between setting the class to frozen, and a field to not frozen could be solved by raising an exception.

Upon investigation, attrs does not support this behavior. I can try this feature with attrs, but their implementation may differ enough to make it infeasible.