Feedback Thread: DIP 1036--Formatted String Tuple Literals--Community Review Round 1

[burt]

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).
>
> 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.

I think that, in principle, the way that is described by the DIP 
is the best way for i"" strings to work. However, I still have 
some points:

* The DIP says the name of the interpolation spec template 
defined in DRuntime is unspecified, but then does specify a name 
for `isInterpolationSpec`. Is this even necessary? I think that 
name should remain unspecified as well.

* The DIP tries to explain the implementation of `toFormatString` 
and `hasAllSpecs` in great depth. But is this even necessary? It 
seems to me that this should actually be an optional mechanic 
(like `idup`) that is implemented by DRuntime as a convenience 
function, and those sections can be removed entirely, which will 
also simplify the DIP, or can be moved to an "optional mechanics" 
section.

* The addition of an optional `alias this` implicit conversion 
only if all the format specifiers are defined seems way too 
complicated for me. My preference would be to add an 
implementation-defined function (just like `idup` now) to the 
template, so users of `printf` can just write:
```d
printf(i"${%d}a + ${%d}b = ${%d}(a + b)".toFormatz());
```
or something. Alternatively, it's not that hard to write a 
wrapper around `printf` which overloads for interpolated strings, 
but an implicit conversion tailored for immutable(char)* seems 
excessive.

* The grammar changes have some issues: "Expression" is defined, 
but this name already exists at 
https://dlang.org/spec/grammar.html#expressions. So, it should be 
given its own name.

* I feel like interpolated strings should work out of the box 
together with `mixin` without requiring a DRuntime CTFE `.idup` 
call.

* As a personal matter, the i"" q{$a + $b} implicit concatenation 
magic seems weird. My advice would be to just add `iq{$a + $b}`.

(* As a minor point, some code blocks don't have the language set 
to D, which would improve readability.)