This is the feedback thread for the first round of Community Review of DIP 1036, "Formatted String Tuple Literals".

===================================
**THIS IS NOT A DISCUSSION THREAD**

Posts in this thread must adhere to the feedback thread rules outlined in the Reviewer Guidelines (and listed at the bottom of this post).

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

That document also provides guidelines on contributing feedback to a DIP review. Please read it before posting here. If you would like to discuss this DIP, please do so in the discussion thread:

https://forum.dlang.org/post/vwrbvacnuerasbphgtjy@forum.dlang.org
==================================

You can find DIP 1036 here:

https://github.com/dlang/DIPs/blob/15537f9b36afa48f1c1cd57468e8c77f8f2499dd/DIPs/DIP1036.md

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

At the end of this review round, the DIP will be moved into the Post-Community Round 1 state. Significant revisions resulting from this review round may cause the DIP manager to require another round of Community Review, otherwise the DIP will be queued for the Final Review.

==================================
Posts in this thread that do not adhere to the following rules will be deleted at the DIP author's discretion:

* All posts must be a direct reply to the DIP manager's initial post, with only two exceptions:

    - Any commenter may reply to their own posts to retract feedback contained in the original post

    - The DIP author may (and is encouraged to) reply to any feedback solely to acknowledge the feedback with agreement or disagreement (preferably with supporting reasons in the latter case)

* Feedback must be actionable, i.e., there must be some action the DIP author can choose to take in response to the feedback, such as changing details, adding new information, or even retracting the proposal.

* Feedback related to the merits of the proposal rather than to the contents of the DIP (e.g., "I'm against this DIP.") is allowed in Community Review (not Final Review), but must be backed by supporting arguments (e.g., "I'm against this DIP because..."). The supporting arguments must be reasonable. Obviously frivolous arguments waste everyone's time.

* Feedback should be clear and concise, preferably listed as bullet points (those who take the time to do an in-depth review and provide feedback in the form of answers to the questions in this document will receive much gratitude). Information irrelevant to the DIP or is not provided in service of clarifying the feedback is unwelcome.

On Tuesday, 8 September 2020 at 10:59:58 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review of DIP 1036, "Formatted String Tuple Literals".
>
> ===================================
> **THIS IS NOT A DISCUSSION THREAD**
>
> Posts in this thread must adhere to the feedback thread rules outlined in the Reviewer Guidelines (and listed at the bottom of this post).
>
> You can find DIP 1036 here:
>
> https://github.com/dlang/DIPs/blob/15537f9b36afa48f1c1cd57468e8c77f8f2499dd/DIPs/DIP1036.md
>

Correct me if I'm wrong, but this proposal is incompatible with scanf.

*) 'scanf' should be added in a section with known limitations.
*) Can you envision a way to solve this issue, in a future more powerful D, without changing the design of this DIP?

On Tuesday, 8 September 2020 at 19:21:49 UTC, Daniel N wrote:
> Correct me if I'm wrong, but this proposal is incompatible with scanf.

int foo;
scanf(i"${%d}(&foo)");

expands to:

scanf(InterpolatedString("%d"), &foo);

then InterpolatedString implicitly `alias this`es itself to:

scanf("%d".ptr, &foo);

which is exactly what is required.

On 9/8/20 3:21 PM, Daniel N wrote:
> On Tuesday, 8 September 2020 at 10:59:58 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review of DIP 1036, "Formatted String Tuple Literals".
>>
>> ===================================
>> **THIS IS NOT A DISCUSSION THREAD**
>>
>> Posts in this thread must adhere to the feedback thread rules outlined in the Reviewer Guidelines (and listed at the bottom of this post).
>>
>> You can find DIP 1036 here:
>>
>> https://github.com/dlang/DIPs/blob/15537f9b36afa48f1c1cd57468e8c77f8f2499dd/DIPs/DIP1036.md 
>>
>>
> 
> Correct me if I'm wrong, but this proposal is incompatible with scanf.
> 
> *) 'scanf' should be added in a section with known limitations.
> *) Can you envision a way to solve this issue, in a future more powerful D, without changing the design of this DIP?
> 

Can you clarify? I believe this would work:

int i;
float f;

scanf(i"${%d}(&i) ${%f}(&f)");

It would be essentially called as scanf("%d %f", &i, &f);

However, I don't know that this is something you would typically do. scanf was not a target for this DIP.

-Steve

On Tuesday, 8 September 2020 at 19:21:49 UTC, Daniel N wrote:
>
> Correct me if I'm wrong, but this proposal is incompatible with scanf.
>
> *) 'scanf' should be added in a section with known limitations.
> *) Can you envision a way to solve this issue, in a future more powerful D, without changing the design of this DIP?

I retract my comment, after reading Adam's and Steven's reply.

I misread a section of the proposal, thinking &var would have to be send as a template param, but it doesn't, so it works fine.

Impressive work!

Do I understand correctly, that

int i = 5;
string someStr = i"Give me ${i} apples";

will not work? In this case it's usage is very limited and this I don't think it should be a new syntax. If it could be replaced with either a template or a trait, it could be the way to go. But otherwise it will be very unintuitive.

On Wednesday, 9 September 2020 at 09:25:26 UTC, Piotr Mitana wrote:
> string someStr = i"Give me ${i} apples";

yourfile.d(3): Cannot assign value of type `interpolated_tuple` to variable of type `string`. Try using `.idup`. Learn more at wiki.dlang.org/interpolation

On Tuesday, 8 September 2020 at 10:59:58 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review of DIP 1036, "Formatted String Tuple Literals".

Scott Meyers has a talk, available on youtube [1], in which he argues that the single most important software design guideline is that "interfaces should be easy to use correctly, and hard to use incorrectly." Let's assume, for the sake of argument, that we all agree with him. (If you do not agree, feel free to disregard this comment.)

What this DIP proposes is an interface that is both hard to use correctly, and hard to use incorrectly. While the efforts taken to prevent misuse are admirable, the burden they impose on programmers who merely wish to use string interpolation as-intended is unacceptably high. Personally, I've supported adding string interpolation to D in the past, but I would not use it if it were implemented as this DIP proposes.

I could point to specific details of the proposal that I think lead to undue complexity, but I don't think I need to. The fact that the DIP authors feel the need to devote as many words to "justifications" of their proposal's complexity as they do to actually explaining it in the first place is evidence enough. They are well aware of what they have written, and of its flaws.

I think the reason the DIP authors have ended up with such a flawed proposal is that they have tried too hard to reach a compromise between mutually-incompatible visions of what string interpolation ought to be. Some people want compatibility with `printf`, and others want compatibility with `writeln`, so we end up with a proposal that's compatible with neither. Some people want implicit conversion to `string`, others want implicit conversion to `const(char)*`, so we end up with explicit conversion required for both. And so on, for each point of contention raised in every previous discussion of string interpolation in D.

This approach is fundamentally flawed. It can lead to Good Work, but never to Great Work [2], and Great Work is the standard that I expect a language addition like this will be held to. As such, I do not think any version of this proposal has much chance of being accepted by the language maintainers. I recommend that this DIP be withdrawn.

[1] https://www.youtube.com/watch?v=5tg1ONG18H8
[2] https://forum.dlang.org/thread/q6plhj$1l9$1@digitalmars.com?page=15

On 9/9/20 10:19 AM, Paul Backus wrote:
> On Tuesday, 8 September 2020 at 10:59:58 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review of DIP 1036, "Formatted String Tuple Literals".

First, thanks for your opinion. We value all the opinions of people in the community, especially long-standing members with a lot of experience with D such as yourself.

However, this entire post has no actionable or specific items, and really should have been added to the discussion thread instead. I'm responding to it here because in the past I have had cases where I posted feedback and got no response or changes, and it irked me.

> 
> What this DIP proposes is an interface that is both hard to use correctly, and hard to use incorrectly. While the efforts taken to prevent misuse are admirable, the burden they impose on programmers who merely wish to use string interpolation as-intended is unacceptably high. Personally, I've supported adding string interpolation to D in the past, but I would not use it if it were implemented as this DIP proposes.

The interface is actually simple to use. Without specific concerns, it's hard to address these comments further.

> 
> I could point to specific details of the proposal that I think lead to undue complexity, but I don't think I need to. The fact that the DIP authors feel the need to devote as many words to "justifications" of their proposal's complexity as they do to actually explaining it in the first place is evidence enough. They are well aware of what they have written, and of its flaws.

This measure of "complexity" is arbitrary, and has no bearing on the validity of the DIP. in fact, many already-accepted DIPS have relatively similar ratios of description and rationale.

One thing to note is that this DIP has a prior very similar DIP, but just used a string for the formatting specification. The Justification section is ENTIRELY devoted to explaining why this DIP does not use that. In fact, we can remove the entire section, and it doesn't change anything about the DIPs features or benefits. But without a distinction between DIP1027 and this DIP, arguably it would be rejected on principle (why approve something that was just rejected).

> I think the reason the DIP authors have ended up with such a flawed proposal is that they have tried too hard to reach a compromise between mutually-incompatible visions of what string interpolation ought to be. Some people want compatibility with `printf`, and others want compatibility with `writeln`, so we end up with a proposal that's compatible with neither. Some people want implicit conversion to `string`, others want implicit conversion to `const(char)*`, so we end up with explicit conversion required for both. And so on, for each point of contention raised in every previous discussion of string interpolation in D.

This assessment is incorrect. There is an implicit conversion of the format specification to immutable char * in the circumstance that you have specified all format information. This makes it compatible with printf.

Implicitly converting the format spec to string would result in undoubtedly incorrect function calls, and we address the concerns quite thoroughly. Even if it is a desired thing, it's not something we should provide. This is not the same as trying and failing. We intend misuse of string conversion to not compile.

I would characterize the DIP as not only trying to address these issues, but succeeding. printf is supported for valid cases. writefln will be supported as expected. Conversion to string or immutable char * is possible with a library call which should be provided. There are no flaws I can see.

-Steve

On Wednesday, 9 September 2020 at 14:19:43 UTC, Paul Backus wrote:
> On Tuesday, 8 September 2020 at 10:59:58 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review of DIP 1036, "Formatted String Tuple Literals".
>
> Scott Meyers has a talk, available on youtube [1], in which he argues that the single most important software design guideline is that "interfaces should be easy to use correctly, and hard to use incorrectly." Let's assume, for the sake of argument, that we all agree with him. (If you do not agree, feel free to disregard this comment.)
>
> What this DIP proposes is an interface that is both hard to use correctly, and hard to use incorrectly. While the efforts taken to prevent misuse are admirable, the burden they impose on programmers who merely wish to use string interpolation as-intended is unacceptably high. Personally, I've supported adding string interpolation to D in the past, but I would not use it if it were implemented as this DIP proposes.
>
> I could point to specific details of the proposal that I think lead to undue complexity, but I don't think I need to. The fact that the DIP authors feel the need to devote as many words to "justifications" of their proposal's complexity as they do to actually explaining it in the first place is evidence enough. They are well aware of what they have written, and of its flaws.
>
> I think the reason the DIP authors have ended up with such a flawed proposal is that they have tried too hard to reach a compromise between mutually-incompatible visions of what string interpolation ought to be. Some people want compatibility with `printf`, and others want compatibility with `writeln`, so we end up with a proposal that's compatible with neither. Some people want implicit conversion to `string`, others want implicit conversion to `const(char)*`, so we end up with explicit conversion required for both. And so on, for each point of contention raised in every previous discussion of string interpolation in D.
>
> This approach is fundamentally flawed. It can lead to Good Work, but never to Great Work [2], and Great Work is the standard that I expect a language addition like this will be held to. As such, I do not think any version of this proposal has much chance of being accepted by the language maintainers. I recommend that this DIP be withdrawn.

I second this. I like this DIP more than 1027, but I fully agree with Paul that in its current form this DIP does too many wrong compromises. Just to re-state my points:

1) I strongly believe that printf shouldn't make up most of the design considerations and DIPs space. This is about a D feature, not C. Trying to bridge both worlds will please none.

2) No C string magic: "spec will automatically convert to a compile-time NUL-terminated C string if spec.hasAllSpecs is true." is just a big NO.

3) `${%d}bananas` is an awful syntax compromise as it will be very unintuitive to newcomers as it's not clear what the variable is.
For example, `${bananas:2f}` would read much better. In general, I like the way Python handles the format specifiers:

https://www.python.org/dev/peps/pep-0498/#format-specifiers

4) Format specifiers need to be 100% customizable. The NodeJS community got this right and it lead to a few awesome libraries. One example that has been mentioned before is https://github.com/chalk/chalk

5) APIs will need to be written specifically to cater for _d_interpolated_strings if no implicit conversion is allowed anyhow, so the interpolated_string struct should always containing its arguments. This would allow for adding methods like `idup`, `toString` etc. directly inside the struct. I don't see the DIP explaining the advantage of doing rewrite magic to `writefln(<interpolationSpec>, apples, bananas, apples + bananas);` and this will only confuse people.
More importantly, it severely restricts the freedom for function designers as they can not accept two interpolated strings nor argument afters the interpolated string.
Note that this also removes most-of the problems with "wrong-use of functions".

6) "if a StringLiteral follows an InterpolatedString, it is appended to the InterpolatedString in the parsing pass (not the lexer pass)". Automatic string concatenation was deprecated for good reasons. This DIP does not provide a good motivation for this nor explains how all the risks learned from this are mitigated.

7) A main use-case for interpolated strings is D mixins. It doesn't address combineing it with token strings  to create D code, e.g. `qi{class D { auto $varName = 20; }`

8) A lot of people want `string k = i"foo $bar";` to work and the DIP should at least a very good explanation why the compiler shouldn't rewrite such assignments to `string k = i"foo $bar".idup;` as it's very clear what the user wants here and the @nogc argument applies to normal strings as well.
In fact, the overload resolution could be changed, s.t. d_to_string struct overloads have a higher priority, but the `string` overloads are still being considered. The compiler would need to implement this logic anyhow to issue the mentioned: "Did you mean to use .idup?" messages.

9) The DIP does not mention operator overloading, e.g.

string s = "foo";
...
s ~= i"foo $bar";

IMHO this is unambiguous and would reduce the need to call `.idup`.