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.

  • \$\begingroup\$ Could you explain the particular answer? I don't read Javascript. \$\endgroup\$
    – Wheat Wizard Mod
    Commented Sep 8, 2017 at 14:29
  • \$\begingroup\$ @WheatWizard The answerer is taking parts of the ASCII-art as the input for right/left. \$\endgroup\$
    – hyper-neutrino Mod
    Commented Sep 8, 2017 at 14:29
  • 1
    \$\begingroup\$ It looks to me that choice in inputs can be exploited harder than in the linked answer by having the inputs be code strings that you exec. \$\endgroup\$
    – xnor
    Commented Sep 8, 2017 at 23:21
  • 2
    \$\begingroup\$ I don't think it's fair to say that this answer violate the loophole "Adding input or rules which weren't explicitly mentioned in the challenge" when the challenge rules say "Given two inputs ... the other being one of two distinct, consistent values of your choice". If there's a spirit of the loophole, I'm not sure what it is past "don't do something unusual that circumvents what the author expected". \$\endgroup\$
    – xnor
    Commented Sep 8, 2017 at 23:28
  • \$\begingroup\$ @xnor I mostly agree with you since I don't think it's exactly that loophole; that's also mostly why I wrote up a separate post to define and create a new loophole for this, if it was decided that we'd need one. \$\endgroup\$
    – hyper-neutrino Mod
    Commented Sep 9, 2017 at 0:27
  • \$\begingroup\$ "Most challenges..." [citation needed]. That aside, the solution is simple: don't write such an easily exploited spec. \$\endgroup\$ Commented Sep 9, 2017 at 13:43

2 Answers 2


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

  • \$\begingroup\$ So essentially the solution is to just write better specified questions? Huh makes sense. +1 \$\endgroup\$
    – hyper-neutrino Mod
    Commented Sep 11, 2017 at 12:15

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

  • 1
    \$\begingroup\$ "It has been fairly broadly accepted..." [Citation needed] \$\endgroup\$ Commented Sep 9, 2017 at 13:44
  • \$\begingroup\$ @PeterTaylor How many challenges would you like me to find to count as a citation? Or do you have some preferred alternative source? If Meta Consensus is fine, this question and its answers seem conclusive unless you disagree specifically with my attempt to formalize "flexible I/O" \$\endgroup\$ Commented Sep 9, 2017 at 15:37
  • \$\begingroup\$ Surely the only acceptable source to back up a statement of that nature is a consensus on meta. \$\endgroup\$ Commented Sep 9, 2017 at 15:41
  • \$\begingroup\$ @PeterTaylor In case you missed my edit, my first paragraph was essentially an attempt to formalize the "flexibility" that was the consensus reached here \$\endgroup\$ Commented Sep 9, 2017 at 16:57
  • \$\begingroup\$ I'm not convinced that any of the answers to that meta-question support arbitrary bijections. In fact, looking at the examples which are given in the answers, for the most part they only seem to be intended to deal with issues around lists (1D and in some cases 2D) of integers. \$\endgroup\$ Commented Sep 9, 2017 at 19:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .