Ternary-operator in Interpolated Strings

[Normanator]

Interpolated strings support fairly involved r-value expressions, but surprisingly not ternary-operator expressions.

const string Approved = "Access granted.";
const string Denied = "Access denied.";
var isAuthorized = true;
var msg = $"{username}: {isAuthorized ? Approved : Denied}";

results in CS1733. Is this something fairly easy to support?

[CyrusNajmabadi]

It's not easy to support due to implementation details around how the colon is interpreted. i.e. because i can write: $"{x:format_specifiers}".

This is a known limitation. The workaround is to simply just surround the expression with parentheses. i.e.

var msg = $"{username}: {(isAuthorized ? Approved : Denied)}";

[svick]

It's not easy to support, see the discussion at dotnet/roslyn#12214.

In short, the issue is that colon in interpolated string is used as a delimiter for format string. For example $"{42:d4}" returns 0042.

Newer versions of the compiler (VS 15.6+) produce a better error message:

error CS8361: A conditional expression cannot be used directly in a string interpolation because the ':' ends the interpolation. Parenthesize the conditional expression.

As the error message explains, the workaround is to use parentheses: var msg = $"{username}: {(isAuthorized ? Approved : Denied)}";

[HaloFour]

@Normanator

Wrap the expression in parenthesis:

bool b = ...;
string s = $"This result is {(b ? "true" : "false")}";

[CyrusNajmabadi]

Newer versions of the compiler (VS 15.6+) produce a better error message:

We also have a fixer to make the change for you:

[bondsbw]

Are there cases where this is actually ambiguous? If the compiler produces an error, then it could take a preferred interpretation.

[Joe4evr]

@bondsbw $"{foo?.Bar:d5}"

[svick]

@Joe4evr How is that ambiguous? .Bar is not a valid expression.

[tannergooding]

I could probably be convinced that this is a change which is difficult to make in the compiler. However, I don't think I am convinced that there is an ambiguous code that would prevent this from working.

I don't believe there is currently any code for which blah ? blah is a valid expression. We only have ?: (ternary), ?. (null-conditional), and ?? (null-coalescing). So there should never be a case where a ? b : C (ternary) is confused with a ? b : c (expression a ? b and interpolation specifier c)

[HaloFour]

I want to recall there being examples posted on CodePlex when the design was being ironed out, but that site has been reduced to an archive which ain't exactly easy to search through. Even if it is possible, what kind of complication would it put on the parser as well as the specification? Is requiring a set of parenthesis really that burdensome?

[tannergooding]

Is requiring a set of parenthesis really that burdensome?

No, I was just indicating that I don't believe there is anything that is truly ambiguous (at least not any code I can think of right now).

[jnm2]

We also have ?[x], but [x] is not a valid expression. (Though #1399 would make it valid.)

[CyrusNajmabadi]

Are there cases where this is actually ambiguous?

@gafter would know for certain. However, as i mentioned originally, it's not necessarily about ambiguity. It also heavily plays into "implementation details around how the colon is interpreted". Right now, for better or for worse, the compiler has taken certain approaches around how parsing and lexing works. Those choices led to the position where either:

1. a lot of work was felt to be be necessary to support this.
2. this construct was disallowed, and the impl could be much simpler.

From my recollection it was an explicit and understood engineering decision to be able to bring about a feature in a timely manner without incurring large costs. Because there is a simple workaround, the team was fine landing there, and hte current situation is one where things are working as designed and intended.

[tannergooding]

From my recollection it was an explicit and understood engineering decision to be able to bring about a feature in a timely manner without incurring large costs. Because there is a simple workaround, the team was fine landing there, and hte current situation is one where things are working as designed and intended.

Right. So now that the feature has shipped, it is probably worth deciding if this should be a long-term backlog item (possibly even "up-for-grabs") to "fix" the compiler to be able to recognize this without the workaround.

It is hit fairly often and just seems like "general goodness" to support (but obviously prioritized appropriately, which is fairly low).

[CyrusNajmabadi]

Right. So now that the feature has shipped, it is probably worth deciding if this should be a long-term backlog item (possibly even "up-for-grabs") to "fix" the compiler to be able to recognize this without the workaround.

Sure. i think that would be fine, as long as any approach didn't substantially increase complexity or risk in the lexer/parser codebases. In other words, i think it's fine to fix this, if the fix is simple. If not, then the same assessment applies and this was an expected tradeoff of language power versus implementation cost. Note that "cost" here refers not just to the cost to actually make it work, but hte cost in increased complexity and decreased maintainability. If we can keep those costs appropriate then addressing this seems fine.

[gafter]

In both the specification and the implementation, the source text of the interpolated string is divided up lexically to decide which parts are expressions, which are format strings, and which are literal parts. Then, once the parts are identified, they are parsed. In other words, first we perform lexical analysis of the interpolated string literal to identify its parts, and then we parse those parts. This division of first performing lexical analysis independent of parsing, and then performing parsing on that result, is a classical approach to they way languages are specified and compilers are implemented.

All of the suggestions I've heard are to have the parsing affect the lexical structure, and to have the lexical structure affect the parsing. While that might be possible, it is quite a departure from the way the language is currently specified and the way the compiler is currently implemented, and (presuming we could find a way to specify and implement it) I expect it would slow down the compiler. In any case it would be a very large work item for fairly small benefit.

[alrz]

the source text of the interpolated string is divided up lexically to decide which parts are expressions, which are format strings, and which are literal parts.

I'm probably missing something but couldn't we just divide up literal parts and interpolations in lexer and then parse interpolations with a e : fs syntax?

[gafter]

@alrz I don't know what fs is. Is it a new hypothetical nonterminal in the language? If so, what would be its syntactic grammar?

[CyrusNajmabadi]

Neal, the way we did this in JS/TS (approximated to C#'s grammar) was to have the following:

InterpolatedString: $" (InterpolatedTextPiece | InterpolatedSubExpr)* "
InterpolatedTextPiece: AnyCharExceptOpenCurlyOrDoubleQuote+ // with the rule about escaping curlies
InterpolatedSubExpr: { Expr (: Specifier)? }

In this manner we treated interpolated strings totally as normal syntax node, and not at all like a token that was then reinterpreted.

The only thing very different here from how we do things today is that the parser has no way to drive the lexer to ask for things like "InterpolatedTextPiece" token. JS/TS solve this by having the parser able to drive the lexer as appropriate for cases like this. In practice it's not problematic (and is necessary given several TS/JS context dependent tokens). However, i agree it would be a departure from how C# currently does things, and it would be complexity we'd have to be very careful about.

With this approach though, format specifiers would not be a problem. The ParseInterpolatedSubExpr production would just consume the open curly, then parse out an expression. It would then see if it was followed by a colon, and if so would parse out the optional specifier.

[gafter]

@CyrusNajmabadi The C# language specification and implementation have separate lexical and syntactic grammars. We cannot treat an opening quote (which appears at the end of your production as a stand-along token) as a token by itself, because it is unambiguously the start of a string. As I pointed out before, the approach you suggest would be a significant overhaul of the specification and implementation, and the benefits quite small.

[HaloFour]

@CyrusNajmabadi @gafter

I'd suggest that it's worth keeping this in mind when discussing possible syntax options for ranges. In the meeting notes most of the examples were written as x..y but x:y and x::y were also mentioned.

[gafter]

The x..y syntax is for start and limit. The x:y syntax is for start and count. We might end up with both. Even without interpolated strings, there is an ambiguity with the conditional expression.