# 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. – Adám Aug 21 '17 at 21:41
• In fact, the K language doesn't even have an AND operator; only Minimum and Multiplication. – Adám Aug 21 '17 at 21:42
• Relevant. – Adám Aug 21 '17 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. – Ad Hoc Garf Hunter Aug 21 '17 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. – James Aug 22 '17 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. – James Aug 22 '17 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. – Mego Aug 22 '17 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 '17 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. – Please stop being evil Aug 23 '17 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. – trichoplax Aug 26 '17 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. – Ad Hoc Garf Hunter Aug 27 '17 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 '17 at 13:02
• @DJMcMayhem: codegolf.stackexchange.com/questions/59116/… it was necessary to ban the library function that makes this trivial. – Joshua Aug 29 '17 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). – trichoplax Aug 26 '17 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. – Adám Aug 21 '17 at 21:47
• Wait, you can upvote on your own answer? – Zacharý Aug 21 '17 at 21:59
• No, which is why my "vote" is in the form of a comment. – Adám Aug 21 '17 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. – James Aug 22 '17 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. – James Aug 21 '17 at 21:50
• @DJMcMayhem Why? – Adám Aug 21 '17 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. – FryAmTheEggman Aug 21 '17 at 23:11
• @FryAmTheEggman The discussion is linked. I'm just making it easy to vote. – Adám Aug 21 '17 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. – FryAmTheEggman Aug 21 '17 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. – Adám Aug 21 '17 at 23:17
• 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. – Peter Taylor Aug 22 '17 at 7:41
• @PeterTaylor I agree, but included it here because someone stated it, apparently in all seriousness. – Adám Aug 22 '17 at 7:51
• @PeterTaylor The argument was more specific to the question. I understand where you're coming from, but all three built-ins which solved the Jelly answer are defined as different things. They're not all a built-in for "given n output n n times". CJam initializing a few variables to the same things is IMO a different situation even if my comment implies otherwise. – nmjcman101 Aug 22 '17 at 14:02
• @nmjcman101 It is perfectly normal for multiple operators to have identical effects on a subset of their domain.E.g. × and + and - and sin() and tan() do the same on the argument 0. – Adám Aug 22 '17 at 14:09
• @Adám Right and then I wouldn't say that any of those are a built-in for "given 0 output 0". They're built-ins for "multiply two numbers" or "add two numbers" etc. – nmjcman101 Aug 22 '17 at 14:13
• @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. – Erik the Outgolfer Aug 24 '17 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". – Riley Aug 24 '17 at 19:47
• The problem with "Here is an opinion, feel free to add justifications for it" is that voting will happen before the justifications arrive, which then result in different voting later on, so that the end result is a mix of votes with no way of judging whether they reflect the community's opinion of the final answer. – trichoplax Aug 26 '17 at 20:44