Command-line flags on front ends

Question

Our standard policy regarding command-line flags states that one should count the space before the dash (-) too, when there aren't any "free" options, since it doesn't exist in the shortest possible invocation. For example this:

language -option program.p

is 8 bytes longer than the shortest possible invocation being:

language program.p

However, in TIO, you don't include a space and instead click a button to add an argument. Also, you don't need to escape it either. This may apply to other online interpreters as well.

One could say that TIO is an implementation of a language, and therefore you can use flags at a lower cost. However, another opinion may be that it's just a front end and doesn't count as an implementation.

So the question is, how should we handle a situation where a front end automatically handles command-line flags with less separators and escaping? Count just like if we use the underlying interpreter directly or not?. Please note that this doesn't apply to "free" flags like Perl's -e, which shouldn't be counted anyways. Also, this question isn't about the front end being an implementation of a language itself, apart from the interpreter used underneath (e.g. interpreter wrappers with special configuration).

This question was inspired by Οurous's doubt for what is being asked here.

Answer 1

Let's solve the flag problem once and for all

Rather than dealing with inconsistent schemes for adding flags, let's just consider each separate invocation of a compiler/interpreter/whatever a separate implementation (and thus a separate language by our rules).

This comes with many benefits:

1. The use of "cheating" flags is less useful, because using those flags means you're using a different language, and thus are competing only with those solutions who also use the same "cheating" flags.
2. It is most consistent with our policy on implementations defining the language. If we view an implementation as a program that takes input and transforms it into output, then it is perfectly reasonable to consider each combination of flags as a different implementation, because the flags change how input is transformed into output - just as we would consider a different program to be a different implementation.
3. Byte count would solely be dependent on the size of the code (barring other rules like storing data in the filename). This is much more reasonable than having to consider how many extra bytes various flags cost by comparing each invocation to a "standard" invocation.
4. This brings languages like C, where external libraries need to be specified on the command line (e.g. -lncurses) in line with languages like Python, where external libraries don't need to be explicitly specified via command-line arguments (if the package is installed, you can import it). This removes an unnecessary penalty for languages without automatic library discovery (and other similar features of which the absence necessitates additional command line arguments).
5. We don't need a list of rules for which flags are free versus which flags aren't. This lowers the barrier for participation for users who are not aware of all of our rules. When the obvious solution is the correct solution, new users can participate more easily.

Answer 2

Commonly used flags are free, unique flags/flag combinations are not

Essentially, the flag problem comes down to differentiating two scenarios. At one extreme, we have languages which are often invoked using certain flags. At the opposite extreme, we have flags or flag combinations which have never been seen prior to a given answer. To me, commonly used flags should be legal, and should cost no bytes. Unique flags, ones which are not commonly used, should be treated the same as code. For instance, in this answer, the flag combination Rss is unique, and should be counted as code, requiring 3 bytes.

The previous answer says that each flag combination is its own language. But that's a bit of a cop-out, because now we essentially have users inventing new languages constantly, without a clear judgement on when that is allowed or not. Referring to this standard loophole, we see that inventing a language for the purpose of a solution is already banned. Read literally, the combination of these two rulings would imply that using unique flag combinations constitutes inventing a language for a challenge, and is therefore banned outright.

I don't think banning unique flag combinations outright is correct, and I don't think allowing them for free is correct. I think the best solution is to count them as code. Note that the - at the beginning of the flag invocation is common to most flags, and therefore is free.

However, this raises the question: How can we objectively determine which flags and flag combinations are common, and which are unique? I think we should do this in the same way we determine whether a programming language exists prior to a challenge, or is made up for the challenge. Ask: "Is this flag or flag combination something that people have used previously? Used purposefully, not just to overcome this rule?" There might be some edge cases requiring subjectivity, but it will almost always be clear.