Is it allowed to take input by repeatedly call a function?

Question

In C, to sum up some numbers, can do:

*X;f(x,n){X=x;x=0;while(n--)x+=*X++;} 
// not sure if return the answer, assuming it does

input a pointer x and the length n

But can also be done by

n;f(x){n+=x;}
#define g(d)d=n,n=0  // 4 bytes shorter

input by repeatedly call f, once a value, then call g(dest) to get the final result into dest

Is it allowed? (Maybe there's shorter solution, but that's not the point)

that(this topic) 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♦ 17 hours ago

Answer 1

No

... unless this is somehow a "standard" way to accomplish some input in a given language.

There are multiple reasons I see for why this would be problematic, which I will present in no particular order.

Technically adds inputs

In some languages or situations, having a single value input multiple times offers fundamental advantages compared to having it input just once. This is a forbidden loophole.

Requires user action not defined in the source code

The consensus here states that a program requiring user interaction between the initial input and receiving output must either A) represent that user interaction as part of the source code or B) follow a known standard. If this was a standard input format for a language then B would apply.

Neither a function nor a program

The default I've seen for PPCG is that a challenge can be answered either with a full program or a single function. The formation listed in this question is neither; rather, it is two functions called independently with different information for different purposes and requires the user to perform special actions on each. It might be possible to avoid this in a way that calling the function multiple times will return the answer on the final call rather than requiring an additional call to retrieve it, but as-written I would consider such a submission invalid even if the input type were not.

Sensitive to initial state

While not an especially strong argument, this method of input would make evaluating a submission much more difficult and time-consuming. TIO and most other online interpreters would be useless, and attempts to form a "test battery" that checks the results of multiple cases in sequence would be at best painful. I wouldn't call that alone a reason to forbid something, but I do much prefer when answers can be easily checked for validity.

Forms a dangerous precedent

Currently, input is mostly accepted in formats that can be obtained through STDIN, read from a file, input as a command-line argument, fed as a bit stream, etc. While formatting is usually flexible, there isn't any current precedent for accepting inputs as things that don't match a language's definition of an input. If these atypical input types are acceptable, then a lot of other input types come into the realm of possibility. For example, if a challenge is "Given a number n, output the current year n milliseconds after epoch time", an answer could be a given language's CurrentYear function and input given as "number of milliseconds after epoch time that the function was called". I don't consider that to be a valid challenge answer, and I also consider both that type of input and input as "number of times the function is called" to be in the same category of "taking input as external state rather than provided values." So rather than trying to decide on a "line" where some external inputs are valid and some aren't, I would prefer to stop the issue immediately.