odd number not necessarily true

[adamdruppe]

Due to normalization, parts always has an odd number of elements. Strings at even indices in parts always originate in the literal fragments of the interpolated string. Strings at odd indices are always string representations of D expressions.

one case we considered with this was

i"$(AliasSeq!(x, y)"

That expansion would break the odd-even rule since the alias seq auto-expands inside the tuple...

since we were marking each individual string literal fragment though it was recoverable (unless you put in an alias seq of interpolated strings, but we deemed that expendable. you could still tell the difference between string parts and expressions and that's more important than telling where exactly a nested i"" ended. but your interpolation header changes that calculation and besides i think nesting a i"" is illegal under your ArgumentList rule so that's conveniently sidestepped. but other tuples do expand into an argument list so still gotta think about it somehow)

but here since it is purely positional i don't think this is actually recoverable. it'd break the thing. The odd/even rule MIGHT hold in the header, if its strings are determined before tuple expansion, but even that ought to be specified and you can still lose sync between the metadata and actual data thanks to the tuple auto expansion.

tbh i'd be perfectly ok with banning it. make it a compile error for an interpolated item to expand into a tuple OR just define that expanded tuple to happen before any processing at all

i"$(AliasSeq!(x, y)"
// identical to if you wrote
i"$(x)$(y)"

So if the expansion is done ahead of time that odd/even rule works again since it inserts empty strings in the middle. So the header here would be like

parts = ("", "x", "", "y")

and the AliasSeq completely disappears. That's prolly the best solution. and might be what the implementation would do anyway but again it just needs to be specified and prolly included in the initial unit test of the feature.

also

(the exact name is uniquely compiler-generated and hence inaccessible)
More sophisticated functions that do want to detect interpolated strings can detect the presence of Header objects by simple introspection.

how do those two things come together? how do you detect that if it has no name and its structure is unremarkable? a new trait?

[schveiguy]

Just as an idea to consider, our DIP used templated structs for the literals, which also was transparent to writeln. This eliminated the need for interspersed empty literals and avoids the problem Adam mentions. One thing I was planning on adding is a header that is not a template which makes overloading much easier. Combined with a trailer, you could then know exactly where all interpolation strings start and end.

Note that it makes things easier for template overloading as well if you have a concrete type accepted at the front.

[Bolpat]

I'd suggest you remove the even-odd rule/guarantee entirely. That way, you actually can be efficient and need not have empty string parts. So i"$a = $b$c" lowers to __header, a, " = ", b, c, no empty strings at the beginning, between, or at the end. It makes the implementation easier and less buggy. If you want to implement a function taking an interpolated string, you need to expect almost anything but two literal parts. The header can carry the information which indices refer to literal strings for example in a bool[] isLiteral.