December 13, 2019
On 12/11/2019 6:55 AM, bachmeier wrote:
>> But this alone gives no way for formatting numbers, so maybe ${%9.6f}{fvar} ?
> My recollection is that in Python 3 that would be done {fvar: 9.6f} or something like that (not a Python programmer).

Both these have parsing problems.

The idea is to keep it parse-able with minimal grammar, which will make it easiest for people to understand.
December 13, 2019
On 12/11/2019 3:45 AM, Andrea Fontana wrote:
> I hoped it was expanded to a function call rather than to a tuple...

Functions currently can't return tuples, meaning you couldn't make it work with printf.

December 13, 2019
On 12/11/2019 5:48 AM, Adam D. Ruppe wrote:
> just use the parenthesis version.

Note that this is similar to how text macros work in the make program.
December 13, 2019
On 12/11/2019 9:49 AM, Meta wrote:
> This DIP is just taking that 1 extra small step to allow i"" strings to be lowered to tuple literals.

You're right. That's really all it does. It will work anywhere a tuple will work.
December 13, 2019
On 12/11/2019 5:00 AM, Sebastiaan Koppe wrote:
> ---
> string str = "work";
> template myTemplate(string str, Args...) {}
> 
> myTemplate!(i"will this %str as expected?");
> ---
> 
> How will the params be passed? Aliased?

As if you wrote:

   myTemplate!("will this %s as expected", str);
December 14, 2019
On 12/11/2019 7:37 AM, Patrick Schluter wrote:
> The transformation is WRONG!

You're quite right. I missed that. With some noodling about with this problem, I've decided to replace the % with $. Then, % just becomes an ordinary character.

Using $ also has the advantage of visually distinguishing a % format string from an interpolated format string.
December 14, 2019
On Saturday, 14 December 2019 at 07:37:49 UTC, Walter Bright wrote:
> It definitely needs to work for printf and writef.

That's an odd requirement, considering you can update writef with the compiler, and printf is legacy.

December 14, 2019
On 12/11/2019 10:40 AM, Anonymouse wrote:
> To preempt any suggestion to just use format with %n$s positional specifiers instead, I present to you non-trivial cases of Bash colour highlighting.
> 
> enum logtint = "\033[1;32m";
> enum warningtint = "\033[1;31m";
> enum resettint = "\033[0m";
> 
> writefln("%3$sException: %1$s%2$s%3$s (at %1$s%4$s%3$s:%1$s%5$d%3$s)%6$s",
>      logtint, e.msg, warningtint, e.file, e.line, resettint);

Not going to use positional specifiers:

1. I don't see much point to them
2. more complexity
3. problems with evaluating an argument multiple times when there are side effects.
December 14, 2019
On 12/11/2019 10:58 AM, Robert Schadek wrote:
> Not being able to use * will stop me using this feature in many places.

That's right. I have a fix for that!

> I thought the idea was not to introduce language changes if a library solution can do most of it already.

I tried. It just doesn't get us there without some awkward syntax.

> TL/DR: not a fan

A reasonable point of view. D works fine without interpolated strings. This also motivated the design to stick to something as simple as possible - just a dash of syntactic sugar.

December 14, 2019
On 12/11/2019 10:47 PM, Ernesto Castellotti wrote:
> This would be really cool

I tried that (the enum in template trick). It's close, but still no banana.
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19