On Monday, 3 February 2020 at 03:06:22 UTC, Adam D. Ruppe wrote:
> The DIP must be amended to specify that ALL % characters in the i"" string are replaced with %% in the yielded string.
> [snip]
> I move that we amend it so the format string literal is not

I withdraw these two motions to amend the DIP and instead second Steven Schveighoffer's change.

I maintain my position that it should work with wide strings though, but I won't hold up my vote for it.

Amendments to my feedback:

6) @nogc should be better supported, supporting C functions isn't sufficient as they lack functionality for custom types. Using .toString() isn't sufficient especially when performance is a requirement. It causes additional allocations/copying that could otherwise be avoided with more robust solution that builds the string in the output buffer.


In addition to points 3/4:

> The DIP is carefully designed to not need to know anything about format strings.

This is exactly the problem. Relevant **required** information is purposefully being withheld from the DIP. I don't agree with it, anyone that wants to do anything more than just use printf and friends needs to know the exact details of the implementation.

> D can (and probably should) add such an extension, but it would be orthogonal to this DIP and should be addressed separately.

It is an extension in C++, but it isn't a language feature in C++. This flies parallel with this DIP which brings printf formatting into the core specification as a language feature. It should be included as part of this DIP, or interpolated strings shouldn't use printf formatting.

On 2/3/2020 7:48 AM, Steven Schveighoffer wrote:
> I propose an incremental change to this DIP.
> 
> Instead of
> 
>      i"a, $b, ${%d}c"
> 
> lowering to the tuple
> 
>      ("a, %s, %d", b, c)
> 
> it lowers instead to the tuple
> 
>      (__d_interpString!("a, ", __d_formatItem.init, ", ", __d_formatItem("%d")), b, c)
> 
> The item returned from __d_interpString shall be defined by the library, but one that implicitly converts to a string or immutable(char)*, with the string contents being identical to the current DIP's format string. It also will provide access to the original sequence as parsed.
> 
> __d_formatItem should be essentially a typedef of string, with a default value of "%s".
> 
> The rationale for this change is twofold:
> 
> 1. Providing an alternative type that decays to a simple string allows specialized handling of such an interpolation via overloading. Some current problems that can be alleviated by this (as identified in the DIP discussion):
> 
>     a. multiple interpolated strings as parameters to writefln. e.g.: writefln(i" ... $a ... ", i" ... $b ... ") can be handled.

No rationale is given why this needs to be supported at all. Note that the user can always write:

  writefln(i" ... $a ... ");
  writefln(i" ... $b ... ");


>     b. Escaping of "%" characters in formatted strings. e.g.: writefln(i"$percentage% complete") will assume the "% c" is a format specifier, but could be overloaded to ignore that '%' if it knows the format string came from an interpolated string.

The user can write writefln(i"$percentage%% complete") as required. Baking % into the specification with special escapes completely weds it to printf/writef formatting, which is carefully avoided (at your request!).


>     c. alternative default format specifiers. For example MySQL uses only the '?' specifier for parameters, so one must prefix EVERY string interpolation parameter with ${?}. If a function overload knows you are using string interpolation, it can generate a proper SQL query without needing those prefixes.

I understand the appeal of this. But it's the same thing as AST macros. It's having the language semantics defined by a hidden template (which happens nowhere else in D). It's undeniably powerful, but way too powerful and not the right path for D.


> 2. The compiler is already doing the work of splitting up the parameters and string data. If the format string is simply passed as a string, then determining the original parsed form (of string + format specifiers) is difficult, if not impossible, and definitely unnecessary if the compiler has already done it.

There's no need to revert it. The D compiler does such "lowering" to simpler forms in many places already.

On Thursday, 30 January 2020 at 09:47:43 UTC, Mike Parker wrote:
> This is the feedback thread for DIP 1027, "String Interpolation".

If
writefln(i"I ate $apples and ${%d}bananas totalling $(apples + bananas) fruit.");
gets rewritten as:
writefln("I ate %s and %d totalling %s fruit.", apples, bananas, apples + bananas);

Than for function:
void my_err_log(string err_msg, string file, int line, int char) {...}

called as:
my_err_log(i"Error loading image $image_path.", src_file, src_line, src_char);

gets rewritten as:
my_err_log("Error loading image %s message", image_path, src_file, src_line, src_char);

Results in an error but users will expect this to work.

Worst case scenario is function that match:
void draw_text(string text, int optional_x = 0, int optional_y = 0) {...}
callad as:
draw_text(i"Today is $day.$month.");


For example, Phobos exceptions are mostly defined as :
this(string msg, string file = null, size_t line = 0)
this(string msg, string file = __FILE__, size_t line = __LINE__, Throwable next = null)
etc.

In my opinion, this is the fundamental flaw in the proposal.

On Thursday, 30 January 2020 at 09:47:43 UTC, Mike Parker wrote:

>
> The review period will end at 11:59 PM ET on February 13, or when I make a post declaring it complete. Feedback posted to this thread after that point may be ignored.

This review round is now complete. Feedback beyond this point may be ignored. The DIP will now move into Formal Assessment for a decision. Thanks to everyone who contributed!