Allow it
It has been fairly broadly accepted that redefining the range of an input or output to some other range, such that bidirectional and unambiguous translation between the two is defined, is accepted even if it is used to shorten code; a simple version would be taking 1
for true and -1
for false instead of the more traditional 1
and 0
.
While I can imagine establishing certain rules that would prohibit excessive abuse like the one linked, such as "every possible value of the input/output's data type must map to exactly one value of the challenge's respective data type", e.g. taking the left/right
input as a string means your program needs to accept every possible string as input and every one of those strings must consistently output either the left result or the right result. This would potentially have prevented that particular problem, but it also is likely to harm a very large number of much smaller abuses like the 1/-1
case as well as opening a can of worms about what defines a "data type" and possibly others. I believe other solutions would result in similar issues.
On the other hand, I don't see this as harmful. While you could argue that the linked answer is problematic, unless we're intending to completely get rid of the consensus that "two distinct values" is often identical to "true/false" with regard to answers here I think the difficulty in "drawing the line" about what constitutes abuse and in designing a method to evaluate whether an answer does so, are excessive. I also don't think that many challenges are vulnerable to using ASCII art to represent distinct states of input, and in the linked answer for example, it may have been significant byte savings but it definitely did not trivialize the problem.
I would only say that this rule becomes invalid if the challenge itself is to perform such a mapping, such as this one, where each distinct input has its own distinct output. In such cases a challenger could simply define their input range as identical to the output range and the challenge is trivially solved (requiring 0 bytes in multiple languages).
exec
. \$\endgroup\$