RFC: "don't omit me!" attribute for variants

[catamorphism]

I just ran into a variation on the following problem: Suppose I have a data type

enum A { B, C}

and some code somewhere else like:

alt check foo {
A {...}
B {...}
}

This says "I know that foo can't be in variant C". But what if I add a new variant D to A? Perhaps I really should add a case to the alt for D (since foo could now be in variant D), but the compiler gives me zero help in this case.

I propose an attribute called no_omit (actually, I don't really care what it's called) to be used like:

enum A { B, C, #[no_omit] D}

which has the effect of generating a warning if any alt check expressions omit the case for D. (I'm not too opinionated about whether it should be a lint warning or an error, so long as there's some way to enable it.) I expect the attribute would be used temporarily, during development, and then removed once the refactor that introduces D is completed.

[nikomatsakis]

Hokey but potentially useful. I assume this would be integrated into the lint pass somehow.

[pcwalton]

I guess this is ok, but I think it's better to just not use alt check. I also think that the ability to have enums derive from each other (as we've discussed) might solve this.

[catamorphism]

Well, I was never in favor of alt check in the first place, so I personally would be fine with eliminating it. If we have to have it, though, this might reduce harm.

[brson]

Since this is mostly for refactoring maybe it could be part of a tool that just tells you all the patterns that fail to mention a certain variant. There have been some other queries I've wanted to make about the code base, like 'what are the dependencies of this module?'

[catamorphism]

@brson True, but IMO, it would be nice to know that right off the bat and not have to remember to invoke a separate tool (and yes, you still have to remember to put in the attribute, but that seems like less overhead than having to invoke a tool). Otherwise, I would probably forget to run the tool, and then I would still not discover the missing case until I saw it as a runtime error.

[pcwalton]

I don't mean eliminating alt check from the language (although I would be fine with that too), but just not using it. The point of alt check is to override the exhaustiveness checking. It seems to me that adding a "don't omit me" attribute is kind of like saying "no wait, override the override", which seems a little excessive to me...

[catamorphism]

That works fine for a single-person project, but not for one where some people don't use alt check but others do :-)

[catamorphism]

In other words, it really means "don't let someone else's code shoot me in the foot".

[pcwalton]

I don't agree that an attribute is less work than a tool; you don't want to check in the attribute, so you need to remember to remove it after you add it. A tool is more foolproof that way.

We're basically talking about static analyses here; simple one-time static analyses shouldn't require modification of the code.

[graydon]

Add a lint pass: #[warn(alt_check)]

Lint pass was made for this kind of thing. Also do one for unsafe and another for unadorned fail while you're in there :)

[thestinger]

It seems that this is still relevant in the presence of _ patterns if there's still interest in implementing it.

[graydon]

I'm not sure. since all matches are exhaustive now, is this really more of a "don't use wildcards on this enum" lint?

[emberian]

Or, more of a "don't consider this variant for wildcarding". Not sure this would be very useful, but a lint wouldn't be bad.

[alexcrichton]

Removing the E-easy label because it's not quite clear where to go with this after its aged so much. I personally feel like exhaustiveness checks supersedes this and that a more appropriate lint would be about not allowing wildcards, but even that's a little difficult to implement.

[thestinger]

If someone is still interested in a feature like this, I think a new proposal should be done based on the current language design.