Encoding data in flexible inputs

Question

Most challenges that take a true/false or right/left or something like that input allow you to pick any two distinct values for these inputs. Recently, this answer came up. Clever use of this specification; however, I feel like this is cheating in some sense, and, as AdmBorkBork points out, it is in spirit a violation of this standard loophole (adding input or rules that weren't explicitly mentioned in the challenge).

One solution is to include these inputs in the bytecount; however, taking "true" and "false" are perfectly normal/reasonable and shouldn't be included. The issue then becomes what should be counted as extra bytes and what shouldn't.

Can we get a decision on what to do? Either always include, make an objective decision process to include the bytes, or never include.

Answer 1

The point of standard loopholes is to cover unacceptable behavior that is broadly applicable across the site. They prevent undesirable solutions to reasonably-specified challenges, by disallowing things that are unacceptable across the entire site.

The sort of loophole abuse in the linked answer is a consequence of the challenge allowing flexible input with little or no restrictions. In that circumstance, it is the fault of the author for that loophole existing, and thus it is the responsibility of the author to close the loophole when writing the challenge. Trying to create a broad rule for the site based off of this one incident would result in failure - any "solution" would be either overreaching ("can't use part of the output in the input" - oops, can't use 1 and 0 as boolean inputs in a numeric output challenge) or insufficient ("can't use strings of the output at least X bytes long as input" - (X-1)-length strings would surely also be problematic).

Answer 2

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).