# Omitting trailing closing parentheses in Excel

When golfing in Excel, it is often possible to omit closing parentheses at the end of an expression. Excel will detect this, add the missing closing parentheses and ask if this is what was meant.

Should any such trailing parentheses be counted for and challenges or not?

• On the side of allowing it is that the code without the missing characters is enough for Excel to understand (though it requires a button press or mouse click to do so).

• On the side of prohibiting it is that the code is invalid, and that Excel will refuse the formula if one rejects the suggested fix.

# No it should not be valid

This site already has a number of rules that new users find surprising. Thus, any rules or exceptions we make should provide enough benefit to outweigh the resulting confusion and need to link to meta posts.

The cost of allowing this comes in the form of surprise and consistency: generally nobody would expect that code which autocompletes to valid code would be considered acceptable, and we make no such allowances for other editors. I think the argument about this being surprising is relatively self-explanatory, in that nobody would guess that print(input( would be a valid Python program. The problem with consistency would then cause us to question why if we allow the IDE behaviour of Excel do we not allow, for example, Python in "IDE X" as answers where the code is autocompleted. I think our current rule, that the code needs to exist in a file in exactly the way it is presented in the submission, is much clearer and will require less meta bloat than allowing an exception would be.

The rule we have about anonymous functions is similar in several ways to this proposed rule, but I believe the key difference is what is discussed above. Both of these rules allow for slightly more freedom in golfing and restricted source challenges, but rarely allow for anything of particular interest. However, what counts as an anonymous function is easily extensible between languages, whereas this rule about a particular editor's behaviour isn't.

• I think the first two paragraphs make this answer weaker. It shouldn't really matter what is most interesting in Excel golf. If omitting parentheses makes Excel more fun then Excel golfers can make a language that compiles into Excel which fills in the parentheses. The last paragraph makes the strongest point and if those other paragraphs are going to hang around I think it would do this answer good to put the strongest point at the front.
– Wheat Witch Mod
Jul 19 '20 at 21:29
• @AdHocGarfHunter I think what I wanted to say was less specifically about Excel and more about what similar rules could accomplish in general. I realise I did not do a good job of communicating that, but I think generally our rules should exist to make our contests better. For example, I think our rules about standard loopholes, or valid submission types exist to make golfing more interesting in general. My view is that these potential benefits matter, but I agree it is less important than the other point. Jul 19 '20 at 21:52

# Yes, it should be valid

If languages like 05AB1E and other golfing languages have implicit bracket closing (albeit, without making any noise, so to speak), then Excel should be allowed to do it too.

Anything that gives a correct result after Excel's typo fixer works its magic should be allowed.

• I don't have any thoughts on the conclusion of this answer but I think the logic behind it is very poor. For one it seems that this logic could be applied to any language, which leads to some undesirable results. For two golfing languages and Excel are pretty different in a lot of ways, but most importantly Excel autofills missing parens while these languages just don't require them.
– Wheat Witch Mod
Jun 27 '20 at 14:25