You might be missing the point when you say this. Based off what you said, I feel that I might not have explained myself well:
The specific bug is that by spreading your type logic all over the program, if you need to update it, you need to find all those if statements to update them.
I’d like to clarify that the assertNever function tells me if a new type was added and it tells me if one was removed.
So I don’t need to “find those if statements” because the compiler will inform me.
But no, the compiler won't tell you. An exception will tell you at runtime. Assuming you tested correctly you may find this before it hits production. But its hard to argue that this is better than just using better coding practices.
if/elseif/... is a code smell. A bad practice if it can be avoided. In this case it can be avoided.
You might be missing the point when you say this.Based off what you said, I feel that I might not have explained myself well:I’d like to clarify that the assertNever function tells me if a new type was added and it tells me if one was removed.
So I don’t need to “find those if statements” because the compiler will inform me.
That is a work around.
But no, the compiler won't tell you. An exception will tell you at runtime. Assuming you tested correctly you may find this before it hits production. But its hard to argue that this is better than just using better coding practices.
if/elseif/... is a code smell. A bad practice if it can be avoided. In this case it can be avoided.
Try compiling this code. The compiler will in fact tell you if you’re missing a case that’s described in the discriminated union.
Of course, that only works if you recompile all your libraries and dependencies. The OO solution would work even if you only recompiled the class.