Although the quoted post is from a different thread about migration tooling, I wanted to discuss it here to avoid derailing that thread. Part of my earlier participation in this thread where I suggested the @preEnumExtensibility attribute was motivated by this topic and I want to return to it because I feel I didn't really get my point across well and this post hopefully provides the right context to try again.
I'm concerned with the idea of actively promoting application of @frozen to existing enums because I don't think it's the right action take in enough cases to make it the default suggestion. If I understand the logic of this approach correctly, it is motivated by the idea package owners will, by default, want to minimize source breaks while adopting EnumExtensibility. To achieve that goal, then, package owners are encouraged to preemptively freeze all of their existing enums, whether those enums were actually frozen or not in practice, and promise to introduce new enums and new APIs using those enums in the future if the need to extend the frozen ones arises. Is that a fair assessment of why we would implement migration tooling for EnumExtensibility this way?
If it is, I worry that the implications of this will be hard to communicate to developers that they are making this promise, and that as a result they may later regret the decision to take the suggestion to mark their enums frozen. In my mind, it would be better to emphasize to developers that adoption of EnumExtensibility is by default expected to be source breaking and to plan their releases accordingly. Developers who are very motivated to mitigate this can do so using appropriate techniques, but my perspective is that doing so is a thoughtful activity that is not conducive to being the default behavior of an automated migration.
My opinion here is of course predicated on the idea that in general, most enums in existence are extensible in nature (that is why @frozen is an attribute and not the default behavior). Is there contention about that? Am I missing something else about this idea?