I think this would allow ternary expressions without the second / false expression, which would be invalid. eg. ? 10 :

I wonder if it might be worth moving this up to the Expression clause on line 148:

Possibly inside the tail.

That way, we can ensure that it always has a Factor after the :.

Good suggestion. I'll look into implementing it.

After further investigation my understanding is that if the operator is ? 10 : like in your example, the greater expression would be [factor] ? 10 : [factor]. I might be missing something, but I don't see how missing the 'false' value is possible.

This is indeed restricted by the fact that the 'false' value is a Factor, while the 'true' value may be an Expression. Could this be fixed with a more recursive definition of Expression? Something akin to

Expression
  = head:Factor tail:(_ Operator _ Expression)*

After changing this locally, the existing tests are still passing. I obviously do not know the project like you do, but what do you think?

That's true for that section, where we explicitly have a Factor after the Operator, but it means that we'd need to ensure that wherever Operator is used, we have a Factor afterwards that is suitable to the ternary operator.

Unfortunately, this isn't the case, as Operator is also used for IntegerOrExpression:

Where ternary operators could cause issues if they include Dice rolls, because the system can't handle things like (d8)d10 or 1d(d10) (Discussed in #206).

Based on the change to Operator, this would be parsed as valid grammar, but will throw an error when run:

(3 < 8 ? 4d8 : 5)d10

I also think the tail part of Expression will now allow things like:

? 10 : 5 ? 3 : 4 ? 20 : 30

Because it allow repetition, and there's no checks to ensure that the part before the ? is actually a true/false expression (Although I'm not too sure we need to care about the latter).

I think it needs to ensure the ternary can't be repeated like that or, if it is, the inner parts are surrounded in parenthesis. e,g:

10 > 5 ? (4 < 6 ? 7 : 10) : 4

After thinking about it for a while, I think it might actually be better to move it into the Factor definition. That way it's available either side of a normal Operator. e.g.:

4 > 5 ? 2 * 3

// technically valid and will output `2`
4 > 5 ? 2 * 3 : 2 * 2 < 2 ? 1 : 2

Looks good. Could you also add tests to check against ternaries with other value types (ie. Dice, math formulas etc), in condition, and the true / false expressions?
And also some tests to make sure that incorrect syntax fails (e.g. missing either true / false expression).

Again, looking good. Would you also be able to add tests to ensure that it correctly handles more advanced expressions as well?
And also some tests to make sure that incorrect syntax fails (e.g. missing either true / false expression).