All of the foregoing are very sage comments.   Consider them well.

To the above I would stress:   “so what?” how many lines-of-code it does or doesn’t take?   It is likely to make precious-little difference in what the runtime engine actually does, but it will make your code less easy to read (therefore, for others to maintain), and, as noted above, it might conceal some pretty serious bugs.   When given a choice between “clever” and “clear,” choose clear.   (Paradoxically, your code might actually run faster.)

Eventually, your “cleverness” will have to be changed, by someone else.   (You shouldn’t have been standing so close to the curb when that bread-truck went by ...)   Business requirements may change, or the addition of some new piece will necessitate changes to the old.   Now, your successor is obliged to, first, “reverse-engineer” what you did, instead of comprehending it instantly, and s/he must devise replacement code, not only for what s/he wants to add, but also to substitute for what the old (obfuscatory ...) code did.   And, to somehow test both.   The return-on-investment disappears pretty fast, if ever it existed at all.   Just do whatever need be done, in the most obvious and “future-proof” way you can muster, test it and move on.