[Discussion] Constant string interpolation

[ashmind]

Problems

There are two relevant cases, and both of them are related to nameof().

1. Consider the following code:

   public static readonly string Sql = $"SELECT {nameof(ColumnX)} ...";
   // moving to a constant
   public const string Sql = "SELECT " + nameof(ColumnX) + " ...";

   Even though nameof is a constant I have to fall back on older syntax here.

2. Another (more insidious) example:

   var sql = new StringBuilder();
   sql.Append("SELECT * FROM " + nameof(C));
   // vs
   sql.Append($"SELECT * FROM {nameof(C)}");

   Even though approaches seem similar, the first one is a constant, while the second one does string allocation — defeating the purpose of a StringBuilder. This can be partially mitigated by having a FormattableString overload on StringBuilder, but FormattableString itself and its internal array would still need allocations.

Solution Discussion

I would like to evaluate string interpolation as a constant in certain contexts (that could only work if all values in it were constants). But I can't think of a simple syntax.

One option could be something like (const)$"A {nameof(B)} C", but I'm not too fond of it.

[svick]

Similar changes were proposed several times before (see e.g. #4678). They were closed, because of issues regarding specific behavior of string.Format() which would have to be maintained.

[ashmind]

@svick Yes -- it's clear that implicit approach cannot work here. However explicit approach can since it would explicitly limit what can be placed in {}. Since const string X = "X" + 5 is not currently supported, I wouldn't even expect (const)$"X{5}" to compile.

So this limits supported scenarios to just strings and nulls I think, and culture or custom formatters will be ignored in the same way as const string X = "X" + "Y" ignores them now.

[ashmind]

A more formal proposal (a bit ad-hoc, not spec-language yet):

If string interpolation expression is interpreted as a constant, it can be compiled to a constant string if: all values in {} can be compiled to constant strings; and there are no formatting specifiers on the values. Otherwise a compilation error will be reported.

An expression is interpreted as a constant if:

1. (Current) It appears at the right hand side of const assignment -- e.g. const string A = $"{nameof(B)}";.
2. (New) It appears within const() expression -- e.g. const($"{nameof(B)}") (similar to checked/unchecked).

[HaloFour]

I don't see how that remedies the issue mentioned by @gafter concerning custom formatting and culture. With this proposal it would be quite possible for the two following expressions to return different values:

const string world = "World";

string greeting1 = $"Hello {world}!";
const string greeting2 = $"Hello {world}!";

[alrz]

context-based constness seem to be not a good option becasue the returned value might vary. I did suggest $$"..." as a culture-agnostic vanilla string interpolation which turns to string concatenations and remains a constant in #9407 but apparently nobody is listening.

[ashmind]

@HaloFour If I understand the problem correctly, the case is "culture that overrides format insertion for string values"? To me it seems like an edge case that would break quite a few libraries as well. I think the spec should just make it clear that culture override is not applied to this case as an official limitation. E.g. select x doesn't call .Select(), so if .Select(x => x) is expected to do weird things some common refactorings can break code — but in practice it's not a problem.

@alrz I've searched for similar discussions, but unfortunately missed that one. I think $$"..." is similar — I suggested const($"") to avoid too many special symbols, but it can go either way depending on what people think. Having it always explicit might be the right way if my answer to @HaloFour doesn't seem convincing.

[HaloFour]

@ashmind Correct. It's fully possible to write a PigLatin culture and set it to the default for the current thread which will rewrite arbitrary string values, e.g.: $"Hello {world}!" becoming "Hello Orldway!".

It may be an edge case, but it's still the prescribed behavior according to the specification and why all of the previous requests to either optimize interpolation into simple concat and/or to permit interpolation in constant expressions have not moved forward.

[alrz]

@HaloFour Edge case you say, the thing is, string concatenation/interpolation should be considered as a low level feature and not something on top of internationalization and culture API which itself is a full-blown disappointment.

[ashmind]

@HaloFour

it's still the prescribed behavior according to the specification

Only in non-constant situation -- we don't have prescribed behavior in constant case yet. Yes, prescribing it not to use culture would be inconsistent -- but is it a problem enough to require explicit opt-in instead? I can't think of a single real-world case where someone could run into it (and if they do, they would have other problems with libs etc).

[bbarry]

Explicit opt-in could make it possible I suppose.

1. amend specification to allow constant-expression to contain string interpolation iff all interpolated values are constant strings (any constant?).
2. permit an explicit conversion to a constant-expression

[mklemarczyk]

String interpolation of a few string constants should be possible without making any changes.
I know that current culture can affect ToString format, but it does not affect if you concatenate only string constants together. I see it as a bug.

[HaloFour]

I know that current culture can affect ToString format, but it does not affect if you concatenate only string constants together.

Concatenation doesn't involve the current culture. Formatting does, and string interpolation is based on formatting. Using String.Format with all const strings still uses the current culture. There's no way to use String.Format to produce a const expression.