Evaluating Ternary Statement - Proposal

[dklompmaker]

Evaluating Ternary Statement

Summary

Utilizing the work already in place for the ternary operator, we can further improve and simplify the language by adding Evaluating Ternary Statement.

Design

The form is very elegant and follows what we already know from ternary operators. In order to avoid ambiguity, the token takes the form ?>.

If Form
{condition} ?> {statement};

If / Else Form
{condition} ?> {statement} : {else_statement};

// From this..
if(condition)
    MethodA();
else
    MethodB();

// To this...
condition ?> MethodA() : MethodB();

// Or if only invoking a single method...
condition ?> MethodA();

Criticism

Simply use if/else in-line

Of course, in the example for the single method execution, we can write:

if(condition) MethodA() else MethodB();

If we were to write this with the proposed form, it would be 5 characters saved:

condition ?> MethodA() : MethodB();

[CyrusNajmabadi]

condition ? MethodA();
if(condition) MethodA();

I see a total of two characters saved...

I'm not getting what improvement this actually brings (esp. as it can't be used in an expression context).

However, this doesn't support an else clause

Sure it does:

if(condition) MethodA(); else MethodB().

[dklompmaker]

@CyrusNajmabadi

if(condition) MethodA(); else MethodB().

This would become:
condition ? MethodA() : MethodB(); Which is actually 9 characters saved.

[CyrusNajmabadi]

To this...
condition ? MethodA() : MethodB();

If you want a brief, single line form of 'if' you can just write:

if (condition) MethodA(); else MethodB();

This really doesn't seem to be saving much. Worse, it seems more confusing you have to read ahead to even know what's happening. 'if' clearly makes it clear that there is conditional flow and statement execution.

[CyrusNajmabadi]

There may be some difficulty in the parser to determine that we are indeed looking for an if statement, however the ternary ? should indicate the expectation.

This is definitely very interesting to parse, and would be tricky to get right (not impossible though). For example, consider that x? is currently legal as a type name. So you have ambiguity there. Now consider:

x? foo<

What's going on at thsi point? A ternary statement, starting with a binary expression? Or the start of a generic local function? :)

[dklompmaker]

This really doesn't seem to be saving much.

On a single line, you'd save 9 characters. In an entire project with thousands of lines of code, that can add up to both file size and time typing. Its much easier to quickly type ? or : than if( and else.

Worse, it seems more confusing you have to read ahead to even know what's happening.

I'm not sure on the criticism here about reading ahead. Take the standard ternary operator example below:

// You have to read ahead to know that it will be 100 if null..
var result = something ?? 100;
// You have to read ahead to know that it can be 10, or 100 if condition passes...
var result = condition ? 10 : 100

// My example, nothing new here nor against standards...
condition ? DoThingA() : DoThingB(); 

This is definitely very ambiguous. For example, consider that x? is currently legal as a type name. So you have ambiguity there.

I'm not sure I follow your point here. In this following example we have both elements:

bool? result = false;
result.Value ? DoSomething() : DoSomethingElse();

// Or if you are concerned about in-line, it would need to be encapsulated...
(bool? result = false).Value ? DoSomething() : DoSomethingElse();

[CyrusNajmabadi]

I'm not sure on the criticism here about reading ahead. Take the standard ternary operator example below:

With an expression, i always know i have to look ahead :)

[CyrusNajmabadi]

I'm not sure I follow your point here.

I'm saying: from a parsing perspective, this is complex. because when you have A.B.C.D? you don't know if that is the type that will be used in a declaration, or if it's the start of a ternary-conditional-statement.

You have to try both routes, and determine which is correct, potentially unwinding and retrying to get it right. If this is a ternay-expression for example, then A.B.C.D is a bunch of MemberAccessExpressions. If it's a local declaration, then these are a bunch of QualifiedNameSyntaxs.

This is not impossible to deal with. I was just addressing your point that:

however the ternary ? should indicate the expectation

This is not hte case. the ? is insufficient to know what's going on here without continuing to look ahead.

[HaloFour]

I'd rather have the structure of the if/else statements. Ternary operators are already difficult to parse visually and aren't recommended for all but the simplest of expressions. Bringing that terseness to statements wouldn't be a good thing. Code should be optimized to be easy to read and understand, not write.

[theunrepentantgeek]

@dklompmaker wrote:

On a single line, you'd save 9 characters. In an entire project with thousands of lines of code, that can add up to both file size and time typing. Its much easier to quickly type ? or : than if( and else.

Code is read many more times than it is written - the overhead of having to puzzle through, working out whether this is a ternary expression, local function declaration or something else altogether, would very quickly overwhelm any savings based on having to type a few less characters.

Further, while not all C# developers use Visual Studio, many do, and those folks can type i f tab to enter if (_) { } in just three keystrokes.

[dklompmaker]

@CyrusNajmabadi

I'm saying: from a parsing perspective, this is complex. because when you have A.B.C.D? you don't know if that is the type that will be used in a declaration, or if it's the start of a ternary-conditional-statement.

Your statement would be true if the parser doesn't hold any knowledge about previous tokens or sibling tokens. I'm pretty sure that the parser can determine between an assignment of a variable from a ternary operator vs. a ternary expression that isn't assigned to a variable.

This is not hte case. the ? is insufficient to know what's going on here without continuing to look ahead.

I'm not an expert in the parsing that is occurring, however instead of looking ahead, you can simply look behind to determine whether a variable is being assigned. This is enough to determine whether to parse for ternary operation vs. evaluating ternary expression.

// Parser knows that we are assigning to variable result...
var result = condition ? "hello" : "world";

// No assignment, therefore we can match against the evaluating ternary expression...
condition ? MethodA() : MethodB();

@theunrepentantgeek

the overhead of having to puzzle through, working out whether this is a ternary expression, local function declaration or something else altogether, would very quickly overwhelm any savings based on having to type a few less characters.

I appreciate your thoughts on this. I don't agree that it would be confusing to read. Take the following example that uses the different ambiguous cases being referenced.

public void OnCompleted()
{
    var resultOfLocalFunction = SomeLocalFunction();
    
   // Variable assignment, so parser doesn't match on this case...
   int? resultOfNullable = true;

    // Again, a ternary returns a value thus doesn't match the expression...
    var resultOfTernary = resultOfLocalFunction ? true : false;

    // We are not assigning to a variable, thus evaluates the ternary statements.
    resultOfLocalFunction ? DoTrueCallback();

    // Local function that demonstrates that it's different than an evaluating ternary expression...
    bool SomeLocalFunction()
    {
         return ...
    }
}

[dklompmaker]

@HaloFour

I'd rather have the structure of the if/else statements. Ternary operators are already difficult to parse visually and aren't recommended for all but the simplest of expressions. Bringing that terseness to statements wouldn't be a good thing. Code should be optimized to be easy to read and understand, not write.

Thanks for your feedback. I'm not suggesting we replace if/else. I'm suggesting that we provide an option for a shorter inline if/else syntax that developers can use.

[CyrusNajmabadi]

I'm not an expert in the parsing that is occurring,

I am :) But this isn't an argument by authority. I'm simply stating, with my actual experience working and developing the parsers for C# and TypeScript, that this is non-trivial. Again, not impossible, but not simple.

however instead of looking ahead, you can simply look behind to determine whether a variable is being assigned. This is enough to determine whether to parse for ternary operation vs. evaluating ternary expression.

This is not sufficient. Again, the case is this: You have A.B.C.D? is that the start of a local function with a nullable-type? like A.B.C.D? Foo<X, Y, Z>(M m, N n, O o) { }? Or is it one of these new ternary statements: A.B.C.D? Foo<X,Y,Z>(M, n, o) : Bar();?

What follows the ? is the same for both cases: Foo<X,Y,Z>(M. That's 10 tokens lookahead here (and it is effectively unbounded). It's not sufficient to just look at what came before. You have to understand what comes after. And you may have to lookahead an unbounded amount. This makes parsing non-trivial. That's all :)

[CyrusNajmabadi]

     // We are not assigning to a variable, thus evaluates the ternary statements.
    resultOfLocalFunction ? DoTrueCallback();`

This is very ambiguous to me. It looks like you're starting to declare a local function called DoTrueCallback() with a return type of resultOfLocalFunction?. Right now, a local function also requires a body. However, that may not always be true. And now we'll have a true ambiguity we'll have to deal with (for example, if we allow PInvoke'd local functions).

[gafter]

If {condition} ? {statement}; is an expression...

• What is its type?
• Why does it have a semicolon?

[dklompmaker]

@gafter

If {condition} ? {statement}; is an expression...

It really isn't an expression because it returns nothing. It's a shorthand for if, if/else. I've renamed the proposal to statement to ensure that there isn't confusion.

@CyrusNajmabadi

This is very ambiguous to me. It looks like you're starting to declare a local function called DoTrueCallback() with a return type of resultOfLocalFunction?. Right now, a local function also requires a body. However, that may not always be true. And now we'll have a true ambiguity we'll have to deal with (for example, if we allow PInvoke'd local functions).

I do see your point. To visualize this issue, let's create an example that would be ambiguous:

public void SomeMethod()
{
    // The concern is that this can be ambiguous to the parser...
    SomeType? SomeInlineFunction()
    {
       ....
    }

   // perhaps ambiguity...
   var SomeType = new SomeType();
   
  // Parse should expect a bool literal, or expression resulting in a bool...
   SomeType != null ? DoMethodA() : DoMethodB();
}

Now, if the parser cannot determine the type of the conditional expression, then I can see where there would be ambiguity. If this is truly an issue, we could enforce a spacing rule on the ?.

Take the string interpolation example of $. You cannot put a space between $ and the target string being interpolated. As such, this creates a rule that can be enforced. However, with nullable types, you can have a space between the type and the ? which creates the ambiguity. If we were to instead enforce that nullable types are defined by: int? <- no space, then this can resolve the ambiguity.

Or, alternatively we can define another character than ? to inform the parser of the intent. Perhaps, something like ?>, but adds unnecessary visual complexity.

[CyrusNajmabadi]

// Parse should expect a bool literal, or expression resulting in a bool...
Now, if the parser cannot determine the type of the conditional expression, then I can see where there would be ambiguity. If this is truly an issue, we could enforce a spacing rule on the ?.

In general, parsers cannot tell this sort of thing. What you are describing is 'semantic directed parsing' and it's definitely not what Roslyn does (for very good reason). For one thing, it becomes nearly impossible to have any sort of incremental-parsing story because you need to know the semantics of the entire world around you to make decisions.

However, with nullable types, you can have a space between the type and the ? which creates the ambiguity. If we were to instead enforce that nullable types are defined by: int? <- no space, then this can resolve the ambiguity.

This would be a breaking change. Existing programs would break. We cannot restrict previously allowed constructs.

:)

[dklompmaker]

@CyrusNajmabadi

This would be a breaking change. Existing programs would break. We cannot restrict previously allowed constructs.

Agreed. I wasn't proposing this as an actual solution, but pointing out the lack of uniformity when it comes to tokens in the space. With @ or $ it expects the quote to begin immediately after without space. My remark was stating that nullable types had followed the in-place semantics that existed prior, then we could theoretically have resolved this without ambiguity.

[CyrusNajmabadi]

Agreed. I wasn't proposing this as an actual solution, but pointing out the lack of uniformity when it comes to tokens in the space. With @ or $ it expects the quote to begin immediately after without space.

That's because hte 'token' there is the entire construct. When you have @"...", this is a single token, defined with a lexical grammar specifying what it shoudl consume. It's teh same reason that ab is not two tokens a and b but just a single 'identifier token'.

This is very common and normal in programming languages. += is a single token + = is not.

In the case of ? there is no inconsistency. It's not that space is allowed between things. It's just that the token is ? and whitespace is allowed between tokens.

[CyrusNajmabadi]

My remark was stating that nullable types had followed the in-place semantics that existed prior, then we could theoretically have resolved this without ambiguity.

The language does not restrict what can go between tokens**. That's pretty much the definition of what a token is :) It's the building blocks that everything is created out of. By definition, trivia (whitespace, comments, etc.) are allowed between them. But trivia is only allowed between tokens. It's not allowed within a token itself.

[dklompmaker]

@CyrusNajmabadi

In the case of ? there is no inconsistency. It's not that space is allowed between things. It's just that the token is ? and whitespace is allowed between tokens.

Fair enough :)

[dklompmaker]

@CyrusNajmabadi
To take this idea to the edge, based on the comments, it seems that it would need a unique token like ?> so that we can avoid parser ambiguity. The drawback here is it begins to become more convoluted than the original design; thus possibly losing any of the simple benefits.

[CyrusNajmabadi]

@dklompmaker Yes. That would work. but then we'd be down to: we already have a good unique tokens for this: if/else :) I don't think there's much desire at make that any briefer.

[Austin-bryan]

// My example, nothing new here nor against standards...
Your example currently doesn't compile, when almost all programmers (even beyond C#) won't expect it to compile, causing people to again look it up.

Also, ?? gets used probably in ever class, at least once, likely even more times than that, hence why it was added. ?: has been around for decades. It's not that often I find myself using code that your solution depends on.

But if you're really bothered by the cumbersome length of the code compared to the simple idea, and feel like putting it all on one line is wrong or whatever (it is), you can write an extension method:

if (condition) MethodA(); else MethodB();
condition ?> MethodA() : MethodB();
condition.Select(MethodA, MethodB);

And frankly, you can get this code even shorter than your example syntax if you can find a shorter word.