# Default for Code Golf: Input/Output methods

It looks like we have a consensus that we want certain defaults for the format which answers are expected in for . On that poll, the question arose twice, which input/output formats should be allowed for programs and functions.

So here is another poll. This one works different though. All the input/output methods are independent of each other, so there will be one answer per method. Upvote all you think are reasonable for the default. Downvote those which you think shouldn't be allowed unless the OP explicitly permits them.

To keep this remotely manageable, I have not posted individual answers for all possible inputs for functions. So there are only four: functions can take input/output via their arguments and return values. Or functions can use any method full programs can. I don't think there is any point in (say) allowing programs to take input from STDIN (only) and to allow functions to take input from ARGV (only) or something like that. If you disagree, please leave a comment.

Note: Some votes have been reverted because they were detected as serial voting. If you vote on multiple answers, please leave some time between votes.

A method is allowed if it has 5 net votes and at least twice as many upvotes as downvotes.

### Update

The current results of the polls are now part of the tag wiki. Please notify me, if results change significantly and the wiki should be amended.

• Related (Can numeric input/output be in the form of byte values) – mbomb007 Dec 13 '16 at 16:10
• "The current results of the polls are now part of the tag wiki" which tag wiki? meta wiki has nothing for code-golf tag. ppcg wiki has codegolf.stackexchange.com/tags/code-golf/info but it's missing a lot of answers here. – Sparr Jul 18 '18 at 18:17

# Functions may output via their return value(s)

• How many languages support this? I support outputting to STDOUT. – user10766 Nov 3 '14 at 0:16
• @hosch250 Wait, are there languages that have functions without return values? o.O – Martin Ender Nov 3 '14 at 0:17
• Oh, that is not considered outputting the last I heard - that is returning a value. If the question asks for a function, this is correct. If the question asks for a program, I support outputting to STDOUT or a file. – user10766 Nov 3 '14 at 0:19
• @hosch250 This particular answer only concerns functions. Whether functions and/or programs are allowed is another question (see the linked meta question, but of course it's ultimately up to the challenge author). But this answers says that if functions are allowed, then they should be allowed to use their return value for the result - as are all other answers here that start with the word Functions. – Martin Ender Nov 3 '14 at 0:21
• Oh, sorry. I definitely will vote on this then. – user10766 Nov 3 '14 at 0:22
• @MartinEnder Most (all?) 8-bit BASIC interpreters do not specifically return a value from a sub-routine, whilst many will allow you to define a mathematical function with the DEF keyword, this is quite limited. I also don't recall Amiga BASIC included with WorkBench having return values from sub-routines but it's been many years since I did any Amiga BASIC so don't quote me on that. 6502/10 assembly does not return values from sub-routines either. If you know that you've stored your result in the accumulator, then you simply use that on return from your sub-routine. – Shaun Bebbers Apr 4 '17 at 8:58
• @MartinEnder Yes, scratch has no return values for it's functions – pppery Aug 27 '17 at 15:51
• @Hosch250 There are languages that don't have STDOUT, like JS – VFDan Jul 3 '19 at 20:39

# Functions may take input via function arguments

• I use this in a lot of my questions, so definitely. – Joe Z. Nov 16 '14 at 22:43
• Can it take array via repeatedly call a function, once a value? – l4m2 Dec 18 '17 at 21:39
• @l4m2 that sounds like a special form of currying and would be worth asking about in a separate question. (In principle, this should be valid, but it's worth discussing explicitly.) – Martin Ender Dec 18 '17 at 21:40

# Programs may take input via GUI prompts

(This is for languages, for which this is the closest alternative to STDIN, like JavaScript's prompt(), Mathematica's Input[] or InputString[], Matlab's input() and VBScript's InputBox().)

• What about for other languages? – Ypnypn Nov 4 '14 at 0:32
• @Ypnypn I'm not aware of a language which can read from STDIN, but where producing a graphical prompt is shorter than that. But in that case, I'd say either is fine. – Martin Ender Nov 4 '14 at 9:22
• @MartinBüttner Matlabs input('') usually just reads from the command line, perhaps you mean inputdlg('')? – flawr Sep 11 '15 at 16:29
• Anyway, Mma's Input and InputString both take the next line of input when run in a script. – LegionMammal978 Nov 8 '15 at 12:35
• @MartinEnder wscript. – wizzwizz4 Jul 21 '16 at 15:47
• Bash read <var> – Stan Strum Jan 7 '18 at 22:09
• So reading choice from confirm and msgbox etc. are also allowed – l4m2 Mar 10 '18 at 8:56

# Programs may output by displaying it on screen.

This makes it possible to use languages like Vim script that can't print output directly to stdout.

Example from this challenge:

$echo "This is a test line!" | vim - -c 'nm Q vEUWvEuWQ|norm Q'  Will display: THIS is A test LINE! ~ ~ ~ ~ ~  Within a Vim session. I think that this way of displaying the result should be valid. I am sure that there are other domain specific languages like Vim script that lacks full I/O support and could use another way to display the result. • Incidentally, vim's output is standard output, but if you processed standard output, there is extra garbage there. – Joshua Jan 25 '16 at 20:04 • It's not even just domain specific languages. I'd say QBasic falls in this category: it doesn't have any concept of an output (or input) stream, but rather writes characters to a "window." – DLosc Sep 3 '16 at 3:51 # Programs may output using their exit code... Exit codes are basically a return value for programs. If functions can output using their return values, it makes sense that programs should be able to do the same. Examples: • Hmm…should this perhaps be "if and only if the challenge requires as output an integer whose value is guaranteed to be between 0 and 255, inclusive"? For example, if the challenge is "output the number of arguments passed to the program," then int main(int argc, char **argv) { return argc; } should not be a valid solution (IMO), because the exit code is masked by 0xFF. (Perhaps this is implicit in the rule as a part of correctness? Just want to be clear.) – wchargin Dec 18 '16 at 5:05 • @wchargin That seems like a limitation of whatever you are using to run your program. I can write a PowerShell script like exit 1000000, and execute it in PowerShell ISE. This gives me no problems. – Rainbolt Dec 19 '16 at 19:14 • Interesting—I didn't know that. As far as I know, this is true on all *nix OSes (including Mac), but I'd be happy to be corrected! – wchargin Dec 19 '16 at 19:21 • is there a reason to limit this to integers? i mean if there's an environment where a program can return something other than an integer why not allow that too? – Jasen Dec 22 '16 at 10:21 • @Jasen I don't see a reason to limit it to integers. – Rainbolt Dec 22 '16 at 14:04 • I'm new to this site. Would a crashed program's exit code considered a valid way of output (for example, SIGSEGV)? – Shmuel H. Jan 9 '17 at 16:04 • @ShmuelH. If you intentionally crash a program (or just use the equivalent of exit(code) in that language) to get a specific exit code, it's valid. – Mego Jan 9 '17 at 16:31 # Functions may take multiple arguments via currying For some functional programming languages like Haskell this is actually necessary, because only single-argument functions exist and functions with multiple arguments are (somewhat transparently) implemented as curried functions. (The alternative would be to take a list or tuple of the values, but that is not how one would naturally write a two-argument function in Haskell.) As per this consensus the same should also be allowable for languages where multi-argument functions do exist. As an example from JavaScript, instead of defining f=(a,b)=>...  and calling it like f(a,b) one could then also define f=a=>b=>...  and call it like f(a)(b). # Programs may take input via command-line arguments # The contents of the tape post-execution may be used as a Turing machine's output • This has my upvote. – SuperJedi224 Sep 22 '15 at 20:54 • Emphasis on the "post-execution". If you allow the final tape of a non-halting turing machine to be considered out, your program can calculate a non-computable function. – PyRulez Dec 10 '18 at 14:15 # Functions may output via the same methods as full programs (This depends on how the poll goes, but could be any subset of STDOUT, STDERR and file.) • This violates the single-responsibility principle, the separation of concerns principle, and I don't think it's really useful in code golf. Moreover, functional programming languages won't let you do that at all, and I want some more love for Haskell. – John Dvorak Nov 3 '14 at 6:42 • @JanDvorak One simple golf use is that print is shorter than return in Python. – xnor Nov 3 '14 at 8:57 • Eugh. Not a fan of that optimisation. What it could be useful for is printing in a loop rather than collecting results in an array. Still not a fan of allowing that. – John Dvorak Nov 3 '14 at 9:02 • @JanDvorak Yeesh, I did not consider that one could print repeatedly to "output" a list. I think that should not be allowed even if this vote passes because the output is not the list that is asked for. – xnor Nov 3 '14 at 9:06 • @xnor Why not, full programs are allowed to do that, too, right? – Martin Ender Nov 3 '14 at 11:22 • @MartinBüttner Hmm, you're right, what a program really "outputs" is the string representation of the result, so this rule should mean functions can too for consistency. But this is another awkward consequence that makes me disfavor this rule. – xnor Nov 4 '14 at 2:15 • what about exit codes? aren't functions suposed to be reusable? if my function exits the program it isn't reusable. that's what the title indicates – Felipe Nardi Batista Oct 26 '17 at 13:14 # Functions may output by modifying their arguments or writing to out arguments Here, "out arguments" refers to arguments that are passed in by reference, so that modifying the value inside the function (as opposed to just overwriting the argument) also modifies the value outside the function (otherwise, the output value would not be observable after the function returns). Note that this is not possible in all languages with all types. • Does this mean that in languages that allow it, the seven characters for return  can simply be replaced with an assignment? – lirtosiast Jun 10 '15 at 21:05 • @ThomasKwa Yes, provided the changed value will then be accessible in the context that called the function. – Martin Ender Jun 10 '15 at 21:18 • so you mean this is only legal in languages that have out arguments, pass by reference, or some similar semantic? for instance not in shell... – Jasen Dec 22 '16 at 10:27 • @Jasen I don't know about shell, but yes to your question. – Martin Ender Dec 22 '16 at 10:31 • This should be clarified to say that you have to actually modify the argument, not just overwrite it. See this for an incorrect use. – isaacg Jun 28 '17 at 9:40 • @isaacg Good point, thank you. – Martin Ender Jun 28 '17 at 9:46 • @isaacg you need to link to a specific revision for that comment to make sense. – Peter Taylor Jun 30 '17 at 19:58 • The revision that I referred to about is codegolf.stackexchange.com/revisions/128782/6 – isaacg Jun 30 '17 at 23:35 # Functions may take input via the same methods as full programs (This depends on how the poll goes, but could be any subset of STDIN, ARGV and file.) • This violates the single-responsibility principle, the separation of concerns principle, and I don't think it's really useful in code golf. Moreover, functional programming languages won't let you do that at all, and I want some more love for Haskell. – John Dvorak Nov 3 '14 at 6:43 • @JanDvorak I don't see the relevance of good coding practices for code golf. And some languages don't even have functions and they aren't necessarily at a disadvantage by allowing functions. The idea of being more liberal in the options for I/O is so that each language can pick what's really shortest. – Martin Ender Nov 3 '14 at 11:10 • The only time that I would object to a function taking input in the same way as a program is if the question was phrased "Write a function that takes the following arguments". This poll applies to questions that are not in such a specific format, so I see no reason to exclude functions that read from stdin. – trichoplax Nov 4 '14 at 13:16 • @MartinBüttner noted. I still don't like this option, but feel free to override my preferences. The vote split is very close to the threshold ATM. – John Dvorak Nov 7 '14 at 9:47 # Programs may combine two or more input methods For example, if the inputs are a string and an int, a function that takes a string as an argument and an int from STDIN would be valid. The input format must still be consistent for a given program. # Programs may output to STDERR • Can anyone give a comment as to why not to? For example, print("Hello, world!") in lua prints to STDERR. – YoYoYonnY Jan 31 '16 at 0:40 • Forbidding output to STDERR seems incompatible with allowing output to the screen. – Dennis May 2 '16 at 18:47 • This should go as standar... Ah. I see. – wizzwizz4 Jul 21 '16 at 16:00 • The only problem I see with this is vagueness between what is written to STDERR by the "language" and what is written by the "program." If a distinction between those is not made, this would permit error quines and answers like this, which is questionably valid. – Esolanging Fruit Dec 29 '16 at 18:29 • I think this shouldn't be allowed by default (but could be explicitly allowed on some challenges). I believe this goes against the spirit of some challenges such as this. On the other hand it could be explicitly forbidden but not everybody will think of this – drolex Jan 27 '17 at 12:36 • This is game-breaking for PHP, where <?=a; outputs a to STDOUT and Notice: Use of undefined constant a - assumed 'a' in [...][...] on line 3 to STDERR. – Ismael Miguel Jan 27 '17 at 14:35 • @IsmaelMiguel This means that outputting to STDERR only counts if that's your chosen output format. – MilkyWay90 Apr 6 '19 at 22:31 • @YoYoYonnY Since when? All Lua 5.1-5.3 output to stdout… – val says Reinstate Monica Jul 17 '19 at 14:16 # For stack-based languages, function's input may be pushed to the stack before calling Stack-based languages may assume that the input for their function is automatically pushed to the stack. • +1, this is the de facto standard for CJam and GolfScript (and probably some other stack-based languages). You might want to make a corresponding answer for output. – Martin Ender Feb 19 '16 at 13:29 • I think the emphasis here needs to be on "function", as opposed to snippet. There's a very fine line between the two... – Sp3000 Feb 19 '16 at 13:34 • Are there any stack based langauges that let you define functions? As far as I am aware most of them do not and do only let you write full programs with IO via STDIO. (in my opinion functions should satisfy (perhaps among other criterions): pieces of code that can be reused in the same program, without typing them out again) – flawr Jul 10 '16 at 16:27 • @flawr Vitsy has functions, in some aspects. There are a few stack-based languages that have scope, but I can't name them immediately. – Addison Crump Jul 11 '16 at 4:12 • @flawr for completion sake: lots (most?) of non-esoteric stack-based languages let you define functions. Factor, Forth, Postscript, Joy, Cat, and many others all have functions (both named and anonymous). dc (the RPN calculator) has registers that can work like functions. – fede s. Sep 14 '16 at 17:35 • @flawr: Underload lets you reuse the functions in question (in a kind-of awkward way, as Underload has no method of naming things, but it's possible and fairly common). – user62131 Jan 15 '17 at 17:05 • Would this apply to a language that has explicit but no implicit IO? – Zacharý Aug 5 '17 at 17:19 # Programs may output to a file • Why are people against this? – xnor Nov 8 '14 at 5:48 • @xnor is /dev/null considered a valid output file? I might as well submit a blank program and claim it outputs the correct answer to /dev/null. – Patrick Roberts Feb 15 '16 at 21:55 • @PatrickRoberts No, /dev/null is not a valid output file, for the exact reason that the output cannot be examined later. "Output to a file" means that you can see the program's output by viewing a particular file. – DLosc Sep 3 '16 at 4:05 • using strace (or chroot, or mv!) you can see what was written to /dev/null – Jasen Dec 22 '16 at 10:30 • @PatrickRoberts But it doesn't output to /dev/null – MilkyWay90 Apr 6 '19 at 22:28 # Input for Turing machines may be written to the tape pre-execution The read-write head should start on the leftmost cell of the portion of the tape containing the input. • This has my upvote. – SuperJedi224 Sep 22 '15 at 20:53 • I think this should only be allowed if that's the only method of input. – mbomb007 Oct 8 '15 at 20:39 • For standard turing machines, it is. – SuperJedi224 Oct 8 '15 at 20:59 • What happened here, SuperJedi? You posted an answer, then commented "This has my upvote" an hour later? – MD XF Oct 31 '17 at 16:55 • @MDXF At the time, several other answers on this question had comments like that added by their authors (including many of Martin's answers). At least one was instead commented "This has my downvote." Basically, it was intended as a way to vote on your own meta proposals because you can't actually upvote or downvote your own answers on this site. Interestingly, most of those comments on this topic seem to have since been removed. – SuperJedi224 Nov 1 '17 at 11:22 • @SuperJedi224 Ah, okay, thanks. I was suspecting sock action, but that makes sense. – MD XF Nov 2 '17 at 16:37 # Where applicable, Turing machines supporting multiple halt states may also output via their halt state This is essentially equivalent to programs outputting via their exit code. • This has my upvote. – SuperJedi224 Sep 22 '15 at 20:54 • Turing Machines as I've seen them defined leave output on their tape and have a single halt state. Is there some precedent for what you are suggesting? – xnor Sep 24 '15 at 16:51 • @xnor: That is usually the case, but I have seen dialects of turing machine code that do support multiple halt states. (For example, in the morphett.info dialect that I usually use, halt is the basic halt state, but any state of the form halt-<any string> is also treated as a halt state.) – SuperJedi224 Sep 24 '15 at 19:09 # Input may be entirely ignored If a challenge specifies that your program should take a certain selection of inputs, but not all of them are necessary for you to solve the task, you can simply not take the ones you don't need. (This is equivalent to taking them via a method that your language doesn't look at, such as via command-line argument in a language which has no access to the command line arguments.) • Are you implying that if the challenge was "take three numbers as input a, b, and c, and return a+b", then print(input()+input()) would be a valid Python submission? – Esolanging Fruit May 23 '17 at 3:20 • @Challenger5: Right. Also that that would be a valid submission if the request was to return a+c. (Even without this, you could still do that by saying, for example, "a and c are input via standard input, and b from a file". This rule's basically meant to avoid the absurdity of having to do that.) – user62131 May 23 '17 at 3:44 # SQLs may take input from a named table which is probably not good enough. But I don't know a better way. • Should be OK, as long as that input is treated as data, not executable code – roblogic Aug 12 '19 at 9:03 # Programs may take input as the value of the last expression Using something like TI-84 BASIC's Ans, which is a variable that stores the value of the last expression. This the shortest way for TI-BASIC to take input, but its validity was recently questioned. To be clear, this is how the process works with Ans: • Within a program, type the input (number, list, string, etc.), followed by a newline to separate statements, followed by the program name, then press Enter. For example, 1337 prgmFACTOR  • Outside a program, type the input, press Enter, then type the program name and press Enter. Edit: I came across a way of using Ans that is similar to command-line arguments, which are allowed: All as one expression, type the input, followed by a colon, followed by pgrmNAMEHERE. For example, 1337:pgrmFACTOR. • I think by definition that submission would not be a full program but a snippet that requires some sort of REPL environment which are disallowed by default. – Martin Ender Feb 25 '16 at 22:53 • I think that TI-BASIC is a special case, it being fundamentally different from other languages, and only being callable from what can be considered a REPL; so what then is to differ a full program from a snippet? – Conor O'Brien Feb 29 '16 at 17:06 • @CᴏɴᴏʀO'Bʀɪᴇɴ I disagree, you can write full programs in the REPL but you can also write them in separate "files" that can be executed. They even support arguments when the program is called, but can also read from stdin or via prompt. – flawr Mar 5 '16 at 12:55 • @flawr On the 84+ series they can't take arguments, and there's no STDIN, only a prompt. – lirtosiast Mar 15 '16 at 16:48 • @lirtosiast According to the official TI 84+ guidebook both commands Input and Prompt are available. Both let the program fetch user input. Both behave alot like e.g. input() in Python or MATLAB. – flawr Mar 15 '16 at 17:59 • @flawr I agree about their similarity; what I meant is that they display a ? that prompts the user to type something. – lirtosiast Mar 15 '16 at 18:00 • @lirtosiast Is that an issue? I think many languages do have symbols to denote new inputs/new lines. – flawr Mar 15 '16 at 18:03 • @flawr It's not an issue. – lirtosiast Mar 15 '16 at 18:04 • @flawr It's worth noting that you can't write full programs in the REPL, at least for the TI-83 and -84 calculators. For example, the Input/Prompt and looping commands can't be used from the REPL. – Jakob Jan 24 '17 at 16:41 • Does this mean using _ for the Python REPL is valid? – Esolanging Fruit Feb 9 '17 at 8:02 • @JakobCornell There are actually assembly programs that let you bypass that – SuperJedi224 Mar 27 '17 at 13:46 # Assembly programs may take input from registers If there are no I/O devices available, an answer might consist of a subroutine that reads its input values from the machine registers. • There's potential for abuse. What if someone creates a machine with a million different special-purpose registers? – lirtosiast Mar 15 '16 at 17:10 • @lirtosiast Good for code colf then. I don't see how that's different from golfing languages with prefilled vars – cat Jul 6 '16 at 0:31 • @lirtosiast I believe the programming language used has to be defined before the challenge starts. – YoYoYonnY Dec 31 '16 at 21:19 • If you golf with x86-64, the standard calling conventions already pass args in registers. So you can just write a normal function that's callable from compiler-generated code. – Peter Cordes Jan 1 '17 at 7:06 • This needs clarification: can we use any register, or only the ones that would be specified to be used by the ABI? – user62131 Jun 11 '17 at 4:14 ## Functions in stack-based languages can leave the output on the stack Mostly for completeness sake. This is the de-facto standard for CJam and GolfScript and probably other stack-based languages. • This is also how Forth works. – mbomb007 Aug 3 '16 at 15:18 • Would this apply to a language that has explicit but no implicit IO? – Zacharý Aug 5 '17 at 17:19 • @Zacharý not sure what you mean? – Martin Ender Aug 5 '17 at 17:21 • A language like Befunge or something similar. Or am I misunderstanding the concept of "function" in these kinds of languages? – Zacharý Aug 5 '17 at 17:28 • @Zacharý Befunge doesn't have functions so this answer doesn't apply. – Martin Ender Aug 5 '17 at 18:42 • I disagree. I think they can leave it on the stack if implicit output is available. There is no way to check if it's left on the stack otherwise. – MD XF Oct 31 '17 at 16:57 • @MDXF Wouldn't that be equivalent to allowing functions in "normal" languages only to use their return value, if the language has implicit output for return values, otherwise there's no way to check if the return value actually has the correct output? – Martin Ender Oct 31 '17 at 17:52 • Yeah, like BIT++ – FireCubez Sep 15 '18 at 18:25 # Assembly programs may write output to some specified memory location If there are no I/O devices available, an answer might consist of a subroutine that writes its output values to some specified memory location (e.g. write a machine word to $0000).

• I think this includes writing to a buffer for outputting multiple values. – qwr Jul 12 '18 at 2:23
• I feel like all these similar posts could be combined into something like "Programs may use registers/variables/memory locations for input/output if no input/output device is available". That would cover assembly programs as well as SQL and other higher level languages with the same problems. – 12Me21 Dec 30 '18 at 19:00

# Assembly programs may read input from some specified memory location

If there are no I/O devices available, an answer might consist of a subroutine that reads its input values from some specified memory location (e.g. read a zero-terminated string starting at \$0000).

• This would be natural for various 8-bit micros. – zwol Mar 1 '16 at 4:50
• and for ms-dos where the command-line is at 80h – Jasen Dec 22 '16 at 10:35
• Seems pretty cheesy for normal x86/x86-64 code. I could use a register as an index into one input, and as a pointer to another input array that started at address 0. (xor edx,edx, mov eax, [rsi+rdx], add eax, [rdx]). I think it's a lot more reasonable to assume pointers to input/output arrays in registers of your choice (even if the standard calling convention uses stack args), except for things like 8-bit micros. – Peter Cordes Jul 17 '17 at 1:51

# Functions may return a list via acting as a generator

In other words, writing a function to return list elements lazily on request, using support that the language already has for doing that, is allowed (currently it's frequently seen but something of a gray area). This would be idiomatic in most of the languages which have it.

• I wasn't aware this was even a point of contention... – Mego Nov 30 '16 at 21:57
• I don't think it is, but we don't have it listed, and converting a generator to a list is fairly expensive byte-wise in Prolog (there's a builtin for it but it has a fairly long name). So I wanted to confirm that I don't have to do the conversion in my Prolog answers. – user62131 Nov 30 '16 at 23:03
• Some things in Python 2 return a list, but in Python 3 it return a generator. Like range. – mbomb007 Mar 3 '17 at 22:46
• @mbomb007 I think Python 3s range is equivalent to Python 2s xrange and Python 2s range is something different... – Roman Gräf Aug 27 '17 at 18:44
• Basically. Python 2's range is like calling list() on the result. – mbomb007 Aug 27 '17 at 19:24

# Functions may return a boolean value via the presence or absence of an error/exception

That is, crashing to return false, and not crashing to return true. This is the function equivalent of outputting via exit code, which is allowed for full programs (nearly all interpreters will return an exit code of 0 by default if the program doesn't crash, and nonzero if it does).

I realised this wasn't on the list while writing a post about how our I/O defaults applied to Brachylog; this method of outputting booleans is idiomatic in most declarative languages (i.e. it's something I'd be likely to write even if I weren't golfing), and it's still meaningful in other paradigms (much rarer, but it's nonetheless considered an acceptable programming technique in industry in languages like OCaml).

I'm not completely convinced either way about whether this should be accepted, although I'm currently mildly in favour (the main point in favour is that it's often the most natural way to do output even if you aren't golfing, and many languages have a try/catch or equivalent to convert it into a regular Boolean; the main point against is that it feels a bit cheap/abusable). However, we could definitely do with a ruling as to whether this is acceptable or not, as there are many cases in which it's going to be the shortest way to write the code, and thus it matters for how answers are written.

• This is pretty much "output via exit code" for functions. +1 from me. – AdmBorkBork Mar 29 '17 at 17:42
• Not sure about this either way, but it would be a significant change for Python golfing. Especially so if a recursive function that keeps nesting is considered a stack overflow error, which is a bit weird since it's common to assume there's unlimited stack depth. – xnor Mar 30 '17 at 8:58
• If anything, I think this should only be allowed in languages with some way of handling errors (usually try/catch). Otherwise, it would be impossible to actually use the code in a program. – 12Me21 Mar 2 '18 at 2:20
• @12Me21 I read "crash" as different to "error" or "exception", where "crash" is always non-recoverable. – Οurous Jul 30 '18 at 21:03

# In languages without any method of input (e.g. ///) programs may get input through an insertion into the source code

• @DLosc What about code in /// that requires changing at the end? E.g. a simple program that adds a full stop to the end of a string if there isn't already a full stop there /.;/;//x///;/.x;/(input goes here); where x is a special character (maybe a newline) that is guaranteed not to be in the input. – boboquack Nov 20 '16 at 9:34
• This is called hard coding. – haykam Feb 28 '17 at 12:33
• @boboquack Can we allow hard-coded input in languages that support input commands? – user85052 Aug 25 '19 at 11:38
• That's a good question, and from experience I would guess no, but you should search on meta/ask your own question here. @A_ – boboquack Aug 26 '19 at 4:05

# Assembly programs may write output to registers

If there are no I/O devices available, an answer might consist of a subroutine that leaves its computed output values in the machine registers upon returning.

• Most calling conventions return integer values in a register, so this is eminently sensible for code fragments and functions. – Peter Cordes Jan 1 '17 at 7:12
• This needs clarification: can we use any register, or only the ones that would be specified to be used by the ABI? – user62131 Jun 11 '17 at 4:14
• This answer is A, yours is B. – CalculatorFeline Jun 20 '17 at 2:15
• @user62131: in real-life hand-written assembly language, you do sometimes write helper functions with a totally custom calling convention that return multiple values in registers that are convenient. i.e. in asm and machine-code answers, you can invent any reasonable calling convention for your function. See my calling-convention answer on Tips for golfing in x86/x64 machine code – Peter Cordes Oct 8 '19 at 18:06