DIP 1027---String Interpolation---Community Review Round 1

[Walter Bright]

On 12/16/2019 9:31 AM, Steven Schveighoffer wrote:
> Why? I mean concatenation of Tuples isn't defined to do anything.

I did concatenate the tuples in the most obvious manner - concatenating them. It 
produces an unusable result.


> But we could define it for interpolated string tuples to be the concatenation of 
> the format strings followed by the AliasSeq of all the fields in order.

Yes, we could, and then tuple concatenation would be useless for any other use 
of tuple concatenation.

> This is the time to make these decisions, because it will be hard to add later. 
> Removing automatic string concatenation was a great addition, but took a long 
> time to get into the language, due to not breaking existing code. I'd hate to 
> have to do it again.

There isn't a better way - and it won't be string concatenation. It'll be 
interpolated string concatenation, as interpolated strings are not strings at all.

>> Since the other method works, I am striving to keep things as simple as 
>> possible. There needs to be very good reasons for gratuitous multiple ways of 
>> doing something, and I don't see one here.
> I'm proposing you DON'T make the other method work (it doesn't now).

It works in the PR I've submitted for this DIP.

> And it's not complicated.

I know supporting iq tokens is not complicated. It's just unnecessary. We can 
always add it later as necessary without breaking things.


>> Of course, then there's "what about qi strings", aaggghhhh.
> That's not grammatically correct. It would be rejected. The "interpolated" 
> property is orthogonal to the string literal method, and must come before it.

D supports u, Lu, uL, U, UL, LU integer literals because I was stupid. At least 
`l` is not allowed.