Enums with Many Cases/Covered Switches

I was reading https://github.com/apple/swift/pull/11098 and it brought my mind back to a strawman discussion that Roman and I had some time ago. Namely, in some cases, we want the functionality of a covered switch, but it would be wasteful to write out all of the cases and fatal error due to the size of the enum (consider ValueKind which I am pretty sure has > 100+ case). So we don't write the covered switch, do use a default case, and, of course when the switch needs to be updated, forgot to update the switch yielding bugs.

Keep in mind I am not 100% sure what the right solution to this is or even if we /should/ solve this solution. But since it is easy for bugs to result from this, a solution to this problem would improve the quality of the compiler. The key thing to notice here is that we actually do not intrinsically care about all of the cases being covered by a switch but rather that the user is notified whenever an enum is changed that a specific switch needs to be re-visited and or updated.

This made me wonder I wonder if we could create some sort of tooling with such an affect. My simple strawman would be to mark a switch as being associated with a specific enum/its cases at a specific revision.

Your thoughts?
Michael

An editor cross-reference feature: show me all switches on this type.
-Andy

ยทยทยท

On Aug 1, 2017, at 10:49 AM, Michael Gottesman <mgottesman@apple.com> wrote:

I was reading https://github.com/apple/swift/pull/11098 and it brought my mind back to a strawman discussion that Roman and I had some time ago. Namely, in some cases, we want the functionality of a covered switch, but it would be wasteful to write out all of the cases and fatal error due to the size of the enum (consider ValueKind which I am pretty sure has > 100+ case). So we don't write the covered switch, do use a default case, and, of course when the switch needs to be updated, forgot to update the switch yielding bugs.

Keep in mind I am not 100% sure what the right solution to this is or even if we /should/ solve this solution. But since it is easy for bugs to result from this, a solution to this problem would improve the quality of the compiler. The key thing to notice here is that we actually do not intrinsically care about all of the cases being covered by a switch but rather that the user is notified whenever an enum is changed that a specific switch needs to be re-visited and or updated.

This made me wonder I wonder if we could create some sort of tooling with such an affect. My simple strawman would be to mark a switch as being associated with a specific enum/its cases at a specific revision.

Your thoughts?
Michael

Terms of Service

Privacy Policy

Cookie Policy