RFC: String interpolation

[alexmccord]

Rendered link.

[matthargett]

Would this support inline if-expressions? eg

print(`The lock combinations are: {if combo then table.concat(combo, ", ") else "unknown"}`)

[alexmccord]

It would. Any arbitrary expressions will fly.

[zeux]

I've been thinking about the delimiter syntax and was wondering about backticks vs $". The RFC has a justification for the backtick in terms of implementation but I'm not sure I fully understand it -- the starting token presumably doesn't matter because it's special, is the difference in the complexity of processing unadorned " when inside an interpolated string?

The benefit of $" is that it might be more compatible with existing syntax highlighters that don't support this syntax.

[Halalaluyafail3]

I dislike the $"..." syntax because it isn't clear if a space can be inserted between $ and "..." (it looks like two different tokens that may have spaces between them), and it is confusing when used to call a function without parentheses (foo$"..." looks like a $ operator).

Having a syntax that affixes a dollar sign to a string seems to imply that all string literals would work, specifically the single quote ('...') and long bracketed strings ([[...]], [=[...]=], etc.), although long strings don't make much sense since they don't interpret escape sequences. If the $"..." syntax was chosen, would $'...' and $[[...]] work?

The benefit of having it compatible with existing syntax highlighters only makes sense if the contents of the string wouldn't have any quotes or backslashes inside of an expression, for example $"a = {string.format("%i",a)}; b = {string.format("%i",b)};" would break existing syntax highlighters.

[zeux]

Yeah the embedded " is a good point. Backtick it is then...

[alexmccord]

fwiw, if you want your string to span multiple lines, we could extend backticks to also work with that? I think that is a backward compatible addition? I can add this into the RFC saying that we may at some point extend backticks to work across multiple lines.

[zeux]

I don't think we need to amend the RFC for the future possibility of the multi-line literals - if we decide to extend this in the future we can just make a new RFC.