All languages should follow the same rules, and being incapable of doing something isn't reason for special treatment. And this would be a big rules change for decision problems in every language.
A good number of existing answers could be easily outgolfed by invoking this new option. For example, on Is this number an integer power of -2?, I can ...
Solution ≠ outputting an expression
I'll phrase this, this way: imagine there is a hypothetical question:
Given n output the sum of all numbers from 1 to n
Okay, so the answer should calculate this. Now let's say I wrote an answer and the output for input 5 is:
Does this seem right? No. But I'm not completely against outputting expressions...
Ask the OP
There are many ways to take input and return output. We've made some standardized ways so that challenges don't have to redefine them every time.
However, for stuff like printing the reciprocal, this is something the OP needs to decide. I don't think it is a stretch of the imagination to think that this could be abused on simpler challenges.
Defaults apply by default (duh), but they do not override the challenge specification. In contrast, the challenge specification can override our defaults in any way it deems fit. Thus, all answers should do what the challenge asks for.
If the challenge asks for a truthy value for primes and a falsy value for non-primes, output a a truthy value for primes ...
As I see it, the difficulty here is that we need to define a standard output format which is both reversible and unique. A standard output format cannot be allowed to vary with the whims of the programmer as that would be open to abuse. However, if for every input there is a unique legal output which clearly contains the desired value, that should be fine. ...
Generally speaking, any readable number format should be valid. This might include:
leading 0s (00045.2)
trailing 0s after decimal point (45.200000)
floating point quirks (0.1+0.2=0.300000000000001 is correct enough, as floating point does this)
fractions to avoid the above, where reduced form is optional, unless specified
I've proposed Programs may write output to the clipboard yesterday and it has received a mixed response (+2/-4) so far. At this point, writing to the clipboard is not a valid form of output by default, and it might very well never become one.
Regarding “Hello, World!”
The challenge states very clearly that the output must be printed to STDOUT, ...
Leave it to the writer of the challenge.
For some challenges, it may be acceptable, for some it may not be. We don't need an official meta consensus on this.
Note: this was first written as a comment, receiving 8 upvotes.
Edit: In general, you may also output to STDERR as a standard method of input/output, but keep in mind that writers of a challenge may ...
Only if it's halting-ness is proven in the post
It is impossible to prove whether any arbitrary program will halt. That doesn't mean that every program can't be proven.
However, the burden of the proof lies with the poster. If they prove that it will (or won't) halt in the post, then I see no problem.
The current consensus on Should Booleans be allowed where a number is required? appears to be that true and false values (not strings) should be accepted in place of 1 and 0 (possibly IFF the language in question recognizes them as such).
Because I had a few spare hours on my hands, I wrote a simple parser / compiler / whatevs that will effectively solve all the problems of this post:
The new language will take input as line-by-line from STDIN (which is allowed) and will hardcode it into a copy of the source program which then gets fed to CBMC.
The output of which gets redirected to a file, ...
You should ask the OP
Consensus exists to help us deem what we think is appropriate for all challenges, not to override what challengers say. The challengers are probably much better equipped to make specific decisions about what is best for their challenge than for us to make sweeping defaults about all challenges.
Note that for decision problems where ...
It's ok iff the solution works in some configuration
For example you can specify "<language> (output to terminal)" in the header.
In my experience, even though languages have buffering by default they tend to only do line-buffer when the output is interactive, so if the code works fine when output to the terminal it's ok.
Outcome for the specific challenge mentioned
I have reconsidered the output requirement following a comment from Neil on the answer in question:
@trichoplax Could you consider the answer as being the ratio of lengths of two specific capture groups? (This would actually make the answer shorter as it takes the trouble to make the whole match be the result.)...
Call the input a natural number \$n\$. I don't see a qualitative difference between:
Returning one number, in a challenge where it so happens that the reciprocal of the correct output is always infinity or a natural number \$≤n\$
Returning two numbers \$(a,b)\$, to represent a fraction \$a\over b\$ where the numerator and denominator are both guaranteed to ...
It depends on what you defines to be the "output" -- it's up to you. In particular:
If you let the output be "the content on the screen when the program terminates", it doesn't count.
If you let the output be "whatever the program writes", it does count.
This is just a small part of "specify your output format" (stdout/stderr/screen).
Allow swapping them by default
Having to negate the truthiness of a certain value sometimes only adds unnecessary bytes to a submission. Unless explicitly overridden in the challenge body, swapping truthy / falsy values should be allowed by default.
Note to challenge writers – You may want to read this meta discussion about replacing truthy / falsy values (...