# Is a "built-in" considered to be so for all challenges it CAN solve, or only the one it is DESIGNED to solve?

This question has arisen after reading this answer to a question prohibiting a built-in which solves the problem. The poster argues that the built-in is not defined as "repeat a single integer a number of times equal to that integer" so it doesn't count as a built-in. However, it was brought up in the comments that it SHOULD NOT be valid because the single command solves the challenge regardless of how it is defined.

A simpler situation was also suggested in the comments. Suppose a challenge requested Boolean AND be performed without using a built-in AND operation. It was noted that both Minimum and multiplication have identical output to AND when restricted to the same input values (1-bit numbers).

Should built-ins designed for one task, which incidentally perform some other task as well, be considered a built-in for both tasks?

• Note that for the answer in question, the OP does consider the built-in prohibited. Still, this meta question stands.
Aug 21, 2017 at 21:41
• In fact, the K language doesn't even have an AND operator; only Minimum and Multiplication.
Aug 21, 2017 at 21:42
• Relevant.
Aug 21, 2017 at 21:47
• This is why I think banning builtins is a bad idea. It only introduces confusion and subjectivity into the question, and really has no benefit.
– Wheat Wizard Mod
Aug 21, 2017 at 23:02

# Stop banning built-ins

It has become sort of a meme at this point, where new challenge posters repeat it as blindly as they repeat “this is code-golf; shortest answer (in bytes) wins”. When asked, and then pressed about the matter, the OP in the linked question couldn’t explain why they banned built-ins.

In reality, there is no reason to do so.

• If you’re compensating for how your own challenge is too simple, then this won’t save it (the Do X without Y problem).

• If you’re trying to rob golf languages of their 1-byte answers, in an attempt to be “fair”, they’ll have 2-byte ones — so who cares? Code golf isn’t an inter-language competition anyway.

• Evidently, as this thread exemplifies, people disagree on what constitutes “using a built-in.”

Personally, I haven’t ever seen a challenge on this website where banning built-ins resulted in higher quality answers — it only leads to arbitrarily constrained ones, and arguments over edge cases like this! I think we should heavily discourage “banning built-ins.”

• Personally, I haven’t ever seen a challenge on this website where banning built-ins resulted in higher quality answers... It probably would have made this challenge better. But other than that, I agree with you. Aug 22, 2017 at 1:05
• Although even though I agree with this post, I don't think it should be a rule, because unfortunately this is more of a cultural issue than a rules issue. Which will make it harder to fix. Aug 22, 2017 at 1:06
• This reasoning is why, in my challenges, I explicitly encourage solutions that don't take advantage of built-in functionality (in the form of "this function/command/whatever does exactly what this challenge asks") in addition to solutions that do. While it's acceptable to use built-ins, we should also encourage solutions that don't use them to show off the power of the language.
– user45941
Aug 22, 2017 at 6:18
• @DJMcMayhem I strongly disagree. The Mathematica answer would simply not have been posted, and all the other ones still would have; so we’d just miss out on a high-quality detailed answer that shows an interesting application of the right tool for the job. The fallacy here is that “if A Simmons had been banned from posting this answer, they would’ve posted a more interesting, non-built-in-using one”, but in reality they likely wouldn’t have contributed at all.
– Lynn
Aug 22, 2017 at 12:22
• Restricted source stuff can be cool. But it basically has to be intentional to be cool, and this isn't that, basically ever. Aug 23, 2017 at 7:34
• I would like to see this as a strict rule. Unless a challenge author can objectively define what they mean by a condition (such as "no builtins") then that condition makes the spec unclear, and the challenge should be closed as such. Aug 26, 2017 at 20:49
• @thedarkwanderer Banning builtins is not even restricted source. Restricted source is much more specific than that. If you want to know exactly what restricted source is about have a look at the tag wiki. It does a better job than I can in a comment.
– Wheat Wizard Mod
Aug 27, 2017 at 6:29
• (Briefly: a restricted-source challenge requires that the submitted code satisfy some objective, computable property, which “no builtins” isn’t.)
– Lynn
Aug 27, 2017 at 13:02
• @DJMcMayhem: codegolf.stackexchange.com/questions/59116/… it was necessary to ban the library function that makes this trivial. Aug 29, 2017 at 18:30

Challenge askers should really be clearer with what they mean when they ban anything.

There really isn't a concrete definition of what a builtin function is. This is just one edge case of what might be considered a builtin, in addition its not clear if more general functions are builtins (e.g. print5of('#') if the challenge was print ##### with no builtins).

Question askers should really be responsible for stating exactly what they mean when they ban builtins just like when they ban comments or libraries. If they don't, just ask them, hopefully they will oblige.

• This seems like a good argument for closing a challenge as unclear if it bans builtins (which I think would be a good policy). Aug 26, 2017 at 20:39

# Yes

Any built-in which performs exactly the prohibited action(s) is prohibited, no matter what.

Feel free to add your arguments for this position to the below list:

• Who cares about intention? x is a built-in function. x accomplishes the task. No built-in function that accomplish the task are allowed. Therefore, x is not allowed.

• A major goal of banning built-ins is to preclude trivial answers. Even a built-in which wasn't documented to do the particular task still trivialize the problem.

• If No became consensus then golfing language authors could just let the description of all their built-ins be this built-in has no purpose to circumvent prohibitions on built-ins.

• This one has my upvote.
Aug 21, 2017 at 21:47
• Wait, you can upvote on your own answer? Aug 21, 2017 at 21:59
• No, which is why my "vote" is in the form of a comment.
Aug 21, 2017 at 22:00
• @Adám Another reason it's nice to only post answers you agree with is that you never have to explain that you agree with your own post, otherwise you wouldn't have posted it. Aug 22, 2017 at 1:03

# No

Prohibitions on built-ins only apply to built-ins for which the stated purpose is identical to the prohibited task.

Feel free to add your arguments for this position to the below list:

• Every code golf answer is a collection of built-ins that accomplish the task.

• If there are other (1 byte) answers that do the same thing so that an answer could be any one of them, then at least all but one are not built-ins for the given task, as there aren't multiple built-ins (one would hope) for any given task.

• A major goal of banning built-ins is to preclude trivial answers which show neither creativity nor deep knowledge; a post which states that a command does what it is defined to do is valueless. In contrast, a post which exposes a command that solves the challenge on its own, in a way which is not immediately obvious from the definition implies some level of creativity or higher-level understanding of the language.

• Built-ins are primarily banned in code-golf challenges; if the challenge bans everything which can solve the problem in 1 byte then they're actually just arbitrarily banning 1 byte solutions in a challenge about reducing bytes. Saying "the winner is the lowest number of bytes, but not lower than N" is something I wouldn't welcome in Code Golf.

• If you don't agree with this answer, it's probably best to leave it for someone who does to post it. Aug 21, 2017 at 21:50
• @DJMcMayhem Why?
Aug 21, 2017 at 21:51
• @Adám If you post this, it won't contain the arguments that someone who actually believes it would have made. These posts are not just for collecting a tally and calling it a day - they're meant to create discussion! I'd recommend you delete this answer, and edit your yes answer to explain your reasoning for it. Aug 21, 2017 at 23:11
• @FryAmTheEggman The discussion is linked. I'm just making it easy to vote.
Aug 21, 2017 at 23:13
• The point is not to make it easy to vote. The discussion should be held here on meta. This isn't just about the one situation, it is meant to describe the policy for all questions. Aug 21, 2017 at 23:14
• @FryAmTheEggman In fact, this is about every situation except the mentioned one, as OP there has already answered. I'll make my answers into Community Wiki's and invite people to edit in their reasons and arguments.
• The second argument is definitely flawed by counterexample. The following CJam built-ins are defined to push the value 0 to the stack: 0, T, U, V. These are defined to push the empty array/string: "", [], L, M, O, Q, R. Aug 22, 2017 at 7:41
• @PeterTaylor Not all of them mean the same. 0 is the 0 literal, T, U and V push the respective variables (which could've been reassigned), "" is the empty string literal, [] isn't even one but two pieces, L, M, O, Q and R push the respective variables. One could argue that the preset values of the variables count as builtins. Aug 24, 2017 at 14:41
• Could I design a language where there isn't a stated purpose for any commands (or the stated purpose isn't the best explanation e.g. + does (a+10)+(b-10)). This way my language can always use "built-ins". Aug 24, 2017 at 19:47