Description

As mentioned in the tips for handling unions in the documentation, one easy way to resolve the union is to incorporate the type name as an additional key during the destructuring / structuring process. I would like to add a disambiguation function of this nature because the need is even more pressing when you deal with subclasses.

At the moment the union resolving strategy is based on unique fields of attrs classes that do not have defaults. It is actually quite easy in the subclassing union type context to get into the situation where one (or all) of the classes participating in the union have unique fields but with defaults. I think that the type name strategy is a good alternative.

I am wondering the following:

• Where does the no default policy comes from? Is it due to the potential of _cattrs_omit_if_default=True argument of make_dict_unstructure_fn?
• If and when PR Subclassing support #312 is accepted, I would like to send another PR with this type name key disambiguation strategy presented as an option before cutting a new release due to the predominance of the problem with subclasses. I already have a proof of concept in the type_disambiguation branch of my fork but I am waiting to have the subclasses API settled (re: customize method of Converter) before sending this new PR.

@Tinche thoughts?