What about adding the opposite of `@Suppress`? E.g...

# stdlib

[Marc Knaup]

What about adding the opposite of @Suppress? E.g. @Enforce.

For example with non-exhaustive when expressions:

‘when’ expression on sealed classes is recommended to be exhaustive, add ‘is …’ branch or ‘else’ branch instead

With @Suppress("NON_EXHAUSTIVE_WHEN_ON_SEALED_CLASS") the warning is gone.
With @Enforce("NON_EXHAUSTIVE_WHEN_ON_SEALED_CLASS") the warning will turn into an error.

That would allow catching missing branches earlier (e.g. when adding a new subclass to a sealed class).
It would even allow developers to turn any warning into an error for specific code, i.e. depending on the use case.

I guess that would be most useful for compiler warnings as the non-exhaustive when warning is an inspection and wouldn’t cause the compilation process to actually fail 🤔

[spand]

Isnt Kotlin in a place where it uses syntax for that kind of thing? I am mostly thinking of override keyword vs. annotation in java

[Marc Knaup]

Not always. Li`ke @Suppr`es`s, @PublishedA`pi and so on.

[simon.vergauwen]

Wouldn’t you rather be able to make certain warnings into errors? Like making NON_EXHAUSTIVE_WHEN_ON_SEALED_CLASS a compile error, and Suppress places where you want to ignore it?

[simon.vergauwen]

I’d be very interested in making the compiler more strict in such places, but rather on a global scope than on a local one.

Otherwise it cannot give additional guarantees in the project.

[Marc Knaup]

@simon.vergauwen non-exhaustive `when`s are certainly not errors and legit code 🙂
Whether exhaustiveness is important depends on the use case.

[simon.vergauwen]

Yes absolutely! I personally would prefer to have it as a compiler error instead of a warning, since the use-cases to have non-exhaustive whens are quite limited in the projects I’ve worked in.

[spand]

In that case you can opt out by using else -> instead of an annotation

[Marc Knaup]

else -> {} and else -> Unit are weird tbh. And changing default behavior would break existing code.

I do agree that non-exhaustive `when`s are a minority :)

[Marc Knaup]

open when? 😄
(assuming new default)

[gian]

If you just want to enforce when exhaustiveness on a local level, you can do something like

inline fun <T> T.exhaustive() = Unit

and then call when { }.exhaustive()

[Marc Knaup]

Yeah that’s a nice workaround. But I’m just looking for a proper solution now 🙂